I wanna know where the parsing of device tree will happen in linux kernel? I mean where can i find the kernel source code to parse all device tree info, all nodes?
TIA.
You can find the parser code here, CONFIG_LIBFDT is config which builds it so look for the Makefile in lib directory, which builds libfdt_files.
Related
I hope somebody can shine me a light. I am using Yocto/Poky with linux kernel sources from a custom repository with an "in-tree" kernel configuration and device tree. (not using fragments or overlays)
When building the kernel stand alone using:
make myconfig_defconfig
make
All the device tree binaries for the configured architecture are built.
When building the same kernel+config within Yocto (Kirkstone), the kernel image is built, but no device tree files.
During Yocto build, a defconfig is generated in "/.kernel-meta/configs"
This config is what I expect and has the correct "CONFIG_ARCH_" set to match the devicetree Makefile.
Compared to the previous setup(s) another machine definition is used (meta-Xilinx), Poky-dunfell changed to Poky-Kirkstone and the kernel is a newer version. (but since this compiles the devicetree when used stand alone, it seems not the cause)
At this moment I have no idea what may cause not to compile the devicetree files.
Any suggestions are welcome.
I'm learning ESP-IDF platform and now want to create a library in order to be able to structure my code properly in the future.
I've done some research and found few things, for instance a library that could be as an example. The only issue with it being too large, I can't clearly see what's the bare minimum for the simplest library code.
What is the minimum configuration for an ESP-IDF static library that can be built into a .a file?
A minimal ESP-IDF component would have an empty component.mk file, C/C++/ASM source file(s), and header file(s) in include subdirectory. At build time, all source files of the component will be compiled and then linked into a static library, which can be found in build/component_name/libcomponent_name.a. This is further explained in ESP-IDF build system documentation.
There are a few such simple components in the ESP-IDF itself, e.g. log.
I need to build mmc_block.ko but with MMC_BLOCK_MINORS=16. I do not wish to build the entire kernel. I am using Ubuntu 15.10. How do I do this?
Dpending on how the Makefile has been written, a module can be compiled out of the kernel tree or in the kernel tree.
Concerning your specific example, I assume the module is the one shipped with the kernel and therefore the Makefile has been written for in-tree compilation. In this case, you can just type make modules to rebuild the module, provided that the kernel has been already compiled (which is a mandatory condition also for out-of-the-tree compilation).
I'm afraid my question is a bit complex. Appreciate anyone who can help.
Some background:
I have a 3rd party SW package that compile both kernel modules and user space applications.
Unfortunately, this 3rd party is very complex, and doesn't use Kbuild for building kernel modules (I tried without success)
When compiling the kernel modules, I add -I{path to kernel headers}, but I see the .config file is not being parsed in the compilation, which, of course, causes many errors.
I tried to manually add all flags from .config to gcc in command line (using a script to generate the command line) but that was a very very long line and gcc couldn't handle it.
So my question would be: Is there a way to force all these flags to gcc somehow?
Appreciate your ideas :)
Clarification:
The 3rd party SW can compile on older kernels (2.6, 2.4) I'm trying to compile it for 3.2
Maybe if someone can explain how the original kernel Makefile manages the .config file, I can mimic that behavior.
After digging in the kernel sources, I found the answer. Here it is in case someone needs it.
There's an automatically generated h file called autoconf.h which contains all the relevant definitions in C pre processor format. Just need to include it manually when compiling the module.
Also in theory, I could use my script to create such a file and include it from the sources.
Hope this helps someone. Now on to the next problem :)
I'm new in writing Linux device driver, and I'm wondering how the kernel Makefile magically knows what to compile. To illustrate what I don't understand, consider the following case:
I did a #include <linux/irq.h> in my driver code and I'm able to find the header file irq.h in the kernel directory KDIR/include/linux. However, this is only the header file, so I thought the irq.c source code must be out there somewhere. Hence, I looked into the KDIR/arch/arm searching for irq.c (since I'm using the ARM architecture). My confusion begins here when I found really many irq.c inside KDIR/arch/arm. To simply list a few, I got:
KDIR/arch/arm/mach-at91/irq.c
KDIR/arch/arm/mach-davinci/irq.c
KDIR/arch/arm/mach-omap1/irq.c
KDIR/arch/arm/mach-orion5x/irq.c
many more...
In my Makefile, I have a line like this:
$(MAKE) -C $(KDIR) M=$(PWD) CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm modules
So I understand that the kernel Makefile knows that I'm using the ARM architecture, but under KDIR/arch/arm/, there are so many irq.c with the same name. I'm guessing that the mach-davinci/irq.c is compiled since davinci is the cpu name I'm using. But then, how can the kernel Makefile knows this is the one to compile? Or if I would like to have a look for the irq.c that I'm actually using, which one should I refer to?
I believe there must be a way to know this besides reading the long kernel Makefile. Thanks for any help!
Beyond the ARCH variable, you can also choose the system type (mach) from the configuration menu (there is actually a sub-menu called "System type" when you type make menuconfig for instance). This selection will include and compile all files under linux2.6/arch/$ARCH/mach-$MACH, and in your case this is how only one irq.c gets compiled.
That aside, it is interesting to understand how the kernel chooses which files to compile. The mechanism behind this is called Kconfig, and it is what allows you to precisely configure your kernel using make menuconfig and others, to compile a module from the outside like you are doing, and to select the right files to compile from simple Makefiles. While it is simple to use, its internals are rather complex - but this article, although rather old, explains it rather well:
http://www.linuxjournal.com/article/6568
To make a very long story short, there's a target make config, which you can trace. That one generates .config, that is your main guideline to making dependencies and controlling what will be compiled, what not, what as module and what will be compiled into the kernel.
This guide should give you a basic understanding of building a kernel module (and I assume that's where you want to start with your driver).