I am adding a gyro/accel driver (Invensense MPU3050), available here to my kernel (LPC Linux). I use LTIB for building the image and rootfs.
I manage in adding all files and the driver is available and compiles perfectly!
Now I need to add a mpu3050_platform_data structure in the i2c_board_info_structure in the "board-generic.c" file (README) and then register it adding some lines in the same "board-generic.c" file.
Problem is, I cannot locate this/these file/s.
Is their name depending on the linux distribution?
Is the same info written somewhere else?
You need to add this to the file supporting the tegra board you are using. In the current 3.0-rc3 kernel (last tag I have checked out), I see these tegra board files (in arch/arm/mach-tegra):
board-harmony.c
board-paz00.c
board-seaboard.c
board-trimslice.c
These files configure the static devices for a given tegra board. Your config file then selects which ones are built. Here are the corresponding config options (from arch/arm/mach-tegra/Kconfig):
comment "Tegra board type"
config MACH_HARMONY
bool "Harmony board"
select MACH_HAS_SND_SOC_TEGRA_WM8903
help
Support for nVidia Harmony development platform
config MACH_KAEN
bool "Kaen board"
select MACH_SEABOARD
select MACH_HAS_SND_SOC_TEGRA_WM8903
help
Support for the Kaen version of Seaboard
config MACH_PAZ00
bool "Paz00 board"
help
Support for the Toshiba AC100/Dynabook AZ netbook
config MACH_SEABOARD
bool "Seaboard board"
select MACH_HAS_SND_SOC_TEGRA_WM8903
help
Support for nVidia Seaboard development platform. It will
also be included for some of the derivative boards that
have large similarities with the seaboard design.
config MACH_TRIMSLICE
bool "TrimSlice board"
select TEGRA_PCI
help
Support for CompuLab TrimSlice platform
config MACH_WARIO
bool "Wario board"
select MACH_SEABOARD
help
Support for the Wario version of Seaboard
Your build system (LTIB) certainly defines one of these config macros (CONFIG_MACH_HARMONY for instance). Look at your config file, see which one is enabled, and add the declaration of your i2c device in the corresponding board-xxx.c file.
Related
I've found various kernel configs in kernel/configs/q.
When I alter them, and run mm in kernel/msm-4.14 the kernel is not rebuilt.
Where do I edit the kernel config, such that a kernel rebuild is forced when mm is run?
The kernel is built separately from the Android platform first. Then the Android platform build system is pointed at where the kernel image is located, using the TARGET_PREBUILT_KERNEL environment variable.
Here is an outline of how I usually configure and build. I have done it this way for both Android 9 and 10, for various vendors. The scheme I use is mentioned in the docs here. Non-Google kernels usually don't come with version control (repo), I don't know what you're dealing with so I'll cover both.
Configuring the kernel
For repo-checkout kernels, you do the config in build/build.config. Basically, after defconfig was taken as basis, you use the ${KERNEL_DIR}/scripts/config tool to alter the config. This usually looks as follows:
POST_DEFCONFIG_CMDS="check_defconfig && update_config"
function update_config() {
${KERNEL_DIR}/scripts/config --file ${OUT_DIR}/.config \
-d CONFIG_SOMETHING_I_DISABLE \
-e CONFIG_SOMETHING_I_ENABLE \
--set-val CONFIG_FOO = 123
}
If you don't have a repo-checkout kernel, locations and details may differ but the basic idea is usually the same: Find/Create the script that kicks of the build, and add invocations of the config tool after making defconfig.
Run the config tool by its own to see full options and more info on its usage, but the above is usually all you need. Beware: If you make syntactically-correct invalid changes (e.g. enable symbols of which the dependencies are not met), the build system will NOT complain and ignore these changes silently. If you face this situation, e.g. use menuconfig to find out what's wrong, as it shows dependencies.
Building AOSP / Making boot.img
After you've built your kernel, you will have Image.lz4 in out/.../dist (or Image.gz in out/.../private/msm-google/arch/arm64/boot). You go to your Android source, and in addition to the usual things (source build/envsetup.sh, lunch) you point the build system at the image you built, e.g. export TARGET_PREBUILT_KERNEL=/path/to/Image.lz4. Then just start the build normally, e.g. make bootimage or m droid.
Note that for Android 10 at least in some cases, you'll have to copy over the kernel modules from out/.../dist too, since the new kernel can't load the old ones. With this part, I am having problems myself at the moment. I think they have to be copied to device/VENDOR/DEVICE (e.g. google/coral-kernel), you may also copy your kernel image there btw, since the original prebuilt one also is there by default. The problem is that at least in my case, the new kernel modules were not copied to device after all.
Use Case:
I am developing a IoT Linux system for my Raspberry Pi. Read Only rootfs is not an option, because I want to upgrade executables on the fly. What I thought is my solution: I develop a tool which can sign ELF-Files (Linux executables and libraries). It signes the sections with some pub/priv key, saves the signature into a section and checks the file before executing it (like DigSig but with the help of openssl-lib). The library loader(glibc) is also modified to check all linux ".so"-libraries before loading it. At the end I want to publish the project and my solution under an open source license. Currently it is not finish and far away from stability.
Develoment state:
ELF-File Sign tool is finished.
Kernel is modified (new security module / own syscall function to check elf-binary signature).
Glibc is modified and patched for my local source.
Quemu is patched to support my new syscall.
Yocto environment is set up. And the image runs on my RaspberryPi 2 test machine.
So far so good. I have the feeling I am very close to my solution.
Now I need to:
Make Yocto / bitbake enable that ALL ELF-Files are signed after the build process. Best would be if the rpm-files have already the signed ELF-files included. And the signing process would be done by one recipe for all the other packages. (So I do not want to create a post installation script which modifies only the files on the root folder).
After searching hours in google and checking the documentation of yocto I have no solution. It would be very great if someone can help me.
I think you can customize package.bbclass in poky/meta/classes, in particular, split_and_strip_files function helps to strip every files
oe.utils.multiprocess_exec(sfiles, oe.package.runstrip)
You can add signing then add your custom tools in poky/meta/lib/oe/package.py
I'm trying to include multiple Metal shaders in my Xcode project which have different language versions, but I'm unable to figure out how to do it.
I'm trying to do this, so I can support the latest features when available and drop back when not.
In the project's settings I can only find a general specifier for the Metal language revision. I also can't find anything in the MSL reference manual to specify it inside the file.
Is this even possible? If so, how?
Thanks in advance.
In Xcode, go to the Build Phases for the target which builds your app. Disclose the compile sources. Select a .metal file. Double-click in the right-hand Compiler Flags column to edit it. Enter -std=osx-metal1.2 or similar. That specific shader source file will be compiled with that language.
I found this compiler flag by comparing the build transcripts of builds with various settings for the target-wide build setting.
I am currently implementing a simple tcp/ip server using an Atmel AT91SAM9260 evaluation board (ARM based micro-controller with several peripherals).
Some examples, given by Atmel include a uIP based web server but uIP cannot handle the throughput needed.
I found the same example based on version 1.1.1 (or slightly above) that was serving me just enough.
Recently I began to have problems with the stack and I couldn't find a port to the AT91SAM9260 with a newer version of lwIP. To build the project, I am using Eclipse+Yagarto+gcc as a development stack.
After just replacing the source code of the latest version 1.4.0 (available at http://download.savannah.gnu.org/releases/lwip/) into my project and attempting to fix all compile errors, I gave up.
The structure of the source code is very similar but apparently there's too many tweaks to be made.
Is there a specific guide on adapting the original source code to my stack? Wasn't the C++ code supposed to just compile on my stack?
At the wiki of LwIP http://lwip.wikia.com/wiki/Projects_that_use_lwIP I do see a reference to contributed ports of LwIP 1.3.0. That may be a starting point, at least for the ethernetif.c file.
To try and answer the second question: The C (not C++) is supposed to compile, but one still has to (at least):
setup lwipopts.h to determine how LwIP is to be used
provide ethernetif.h/ethernetif.c to tie your hardware to LwIP
setup sys_arch.h/sys_arch.c
I've created, debugged, and revised a project that I've been working on, but now I want to be able to specify what version of the binary I'm on. I'm using Eclispe-CDT with MinGW to make this project on my local system, so there is no versioning software involved. Does anyone know how to specify this for both Windows and Linux platforms?
On Windows, the idea is to produce a COFF file with the relevant information.
That is done by adding a step to the build, using windres (found also here).
See this thread as an example.
you could add windres via the project properties/Builders as an additional builder and add the generated object file in the C/C++ Build/GCC C++ Linker/Miscellaneous/Other Objects.
Then you
- a) could do a clean build if the resource is changed or
- b) could change the build options (if you have patience) to change to do a clean build every time you save the project.
On Unix, this doesn't seem to be supported in a similar fashion.