I'm creating images for iMX chipsets and had downloaded the sources from NXP, and then created a core-image-minimal using Yocto. I then proceeded to sucessfully boot the image in a board.
After that, my interest was to apply the EVL project on an image. I did the following:
Download the sources from EVL Core. Those sources consist of a Kernel with EVL on top of it.
Created a workspace folder using devtool, and added the folder linux-imx, which contains the code for the kernel.
Completely replaced the contents of the folder for those of EVL. The rest of Yocto files remained unchanged.
Rebuilt the image and flashed it.
However, when booting, I get the following message:
Starting kernel ...
E/TC:0 0 dt_find_ocram_tz_addr:71 Cannot find fsl,optee-lpm-sram node in the dev ice tree
E/TC:0 0 Panic at core/arch/arm/plat-imx/imx_ocram.c:73 <dt_find_ocram_tz_addr>
E/TC:0 0 Call stack:
E/TC:0 0 0x14005411
I checked the EVL kernel code, and in arch/arm it contains no folder named plat-imx. This is rather confusing, since the problem appears in a line of code that doesn't exist in my workspace folder.
I tried checking the defconfig files in order to see where Yocto was taking the kernel code from, but couldn't find anything meaningful.
Any help is greatly appreciated.
Thanks in advance
As said in the comments, the problem was the following:
I couldn't find the folder plat-imx because it was not in the Kernel folder, but rather in the OP-TEE folder.
OP-TEE, which is a safety environment, runs before the boot checking the device tree and updating some memory addresses based on that.
Since the device tree had changed, he was now unable to find some elements and therefore it crashed before boot.
After adding some missing files to the DTS folder, the Bootloader worked correctly. Other problems during boot due to the kernel change appear remain to be solved.
Related
If you want to modify the linux kernel such that it excludes certain modules, you usually go to /kernel/msm-4.9/arch/arm/configs/vendor/<machine-name>_defconfig, which has a bunch of Kconfig symbols, and the ones I want to exclude are commented out, as shown below.
CONFIG_PPP=y
#CONFIG_PPPOL2TP=y
CONFIG_PPP_ASYNC=y
Then I build the linux image by running bitbake virtual/kernel which should ideally have my changes integrated, but when I boot the image, I still see some of the logs of the commented module showing up.
I checked yocto documentation and looks like they create a patch of the file they want to modify, and then append that modified file in the .bbappend file like:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://0001-calibrate-Add-printk-example.patch"
So in my case, if I were to modify /kernel/msm-4.9/arch/arm/configs/vendor/<machine-name>_defconfig, I would:
create a copy of this original file
paste it into poky/meta-bsp/recipes-kernel/linux-msm/files
rename it
include this file in the .bbappend (as shown above)
But how will the above patch override the original /kernel/msm-4.9/arch/arm/configs/vendor/<machine-name>_defconfig that I planned on modifying by this approach?
You are right, sources modifications are done with help of patches in Yocto. Answering your question
But how will the above patch override the original /kernel/msm-4.9/arch/arm/configs/vendor/_defconfig that I planned on modifying by this approach?
it is done automagically:)
That is, build system (bitbake) automatically detects files with extension .patch among SRC_URI content, copies those files from meta-layer directory to build directory somewhere under build/tmp/work/... and automatically applies thous patches on source code (sources directory is defined by S variable in recipe).
But there are some recommendations about other stuff in your question. Some concepts here, skip it to the right way is or even fast way below if bored))
One of the main ideas behind Yocto is reproducible and extensible builds. That means, that all metadata is split into different repositories (that is layers), that are maintained by different teams. Basically teams do not have access to each others repos and none has access to some external project (kernel in your case) source code. Of cource, one may create git-forks of all this, but this is way more complicated than writing metadata. That's why Yocto was created - to take external metadata (ex., poky layer), source code ('kernel') and make it work only by writing your one metadata (your own layer), with no any git-forks.
So, adding your patch and .bbappend to poky layer make no sense, because you wouldn't be able to commit poky layer and distribute this to your customers - poky layer belongs not to you) You may create git-fork however, but that complicates the process of distribution.
That's why the right way is:
create your own BSP-layer
create .bbappend in your layer
add patch to the kernel in your layer (actually the right way is to use .scc files, put patch also will go)
This shall make your build
reproducible - rerunning kernel compilation, or even fresh clone of Yocto with your BSP-layer, would be able to produce the same kernel
distributable (extensible) - customers need only your BSP-layer, other Yocto stuff may be found on internet
And finally, the fast way. If you don't need all this reproducible and extensible but just build some stuff for your home-project and send Yocto to trash, hack the build like this:
clean all kernel-stuff you have bitbake -c cleansstate virtual/kernel
get kernel sources (clone and patch) bitbake -c patch virtual/kernel
handle manually everything you need in kernel sources, found somewhere on working stuff like <TOPDIR>/build/tmp/work/<machine-name>-poky-linux-gnueabi/linux-yocto/<version>/git
build the kernel bitbake -c package virtual/kernel (cloning and patching would be skipped, as bitbake remembers this tasks are done; kernel build artifacts wouldn't be removed, because task rm_work goes after package, and kernel stuff actually is never removed)
But in this case, if this kernel stuff is removed, or breaks somehow, you'll have to walk through this algorithm again (remember - not reproducible).
To easy rebuild the kernel manually (not through bitbake) you can run script <TOPDIR>/build/tmp/work/<machine-name>-poky-linux-gnueabi/linux-yocto/<version>/temp/run.do_compile
I just built the linux kernel for CentOS using the instructions that can be found here: https://wiki.centos.org/HowTos/Custom_Kernel
Now, I made my changes and I would like to rebuild the kernel and test it with my changes. How do I do that but:
1. Without having to recompile everything. So, build process should reuse whatever object files generated by the first build that wont need to be modified.
2. Without having to build the other packages that are build with the kernel (e.g., debuginfo, tools, debug-devel, ...etc.).
Thanks.
You cannot. The paradigm of rpmbuild is to always start from a clean slate to ensure reproducibility and predictability. The subpackages would be also be invalidated because they depend on the exact output of your kernel build, e.g. locations within the binary images where certain symbols are defined, that may have changed when you rebuilt it.
I want to add several devicetrees from my hardware projects into my kernel sources, regardless of the kernel version. Currently I'm using pyro with linux-xlnx_2017.1 and I want to switch to rocko the next time.
So i have sevaral .dts files in my custom meta-bsb layer, which i want to include. I tried to make a recipe include-hw-dts.bb, but it doesn't work properly. I'm afraid the patch isn't applied, when running *bitbake virtual/kernel".
So in short: Is there a way to add a bunch of files into my kernel sources, without updating the recipe for each new kernel version / xilinx linux release? I would like to store my .dts files directly in my layer and not using patches if possible.
This a certainly a dumb question, but when I look at the sources of the linux kernel of raspberry pi (here : https://github.com/raspberrypi/linux), this is not the same as the root organisation (that you can find here : http://labor-liber.org/en/gnu-linux/introduction/tree). However, there are some similarities (ex : usr repository).
Do someone know why?
Thank you!
Kernel sources are files for build the kernel. Usually, these files are located in some directory. After building (and installing) sources can be safetly cleaned.
Root directory is the top-level directory for working OS.
Most of subdirectory names common between between kernel sources and root directory are just accidental coincidence.
First link only contains the kernel source code; which you need to compile and then you can replace the kernel image and modules on the target.
While the second link shows the filesystem tree; it means how the files and directories are organised in the linux.
In some cases (depend upon the type of flashed OS ) you can see your kernel source code (which you have mentioned in the first link) in your running OS as well inside the /usr/src/<kerne_path> directory.
I am working on ZedBoard(having Zync series SoC from Xilinx) and want to create a device tree for the embedded linux which i am planning to boot on this Zedboard. I followed the two links
http://xillybus.com/tutorials/device-tree-zynq-1
http://www.wiki.xilinx.com/Build+Device+Tree+Blob
They both gave me insight of device tree.
Now I have two options:
I got one prebuilt device tree .dts file for the Zedboard. So, can I use this directly without changing anything and only add mine needed drivers in this and it will work?
or
Should i start from scratch and generate mine own device tree .dts file.
What i want to ask/confirm that: device tree(.dts) file is not project specific and the content of .dts file will be unique for the particular board(which is in our case is ZedBoard). So i can take one working .dts file(as in option 1) as a basic platform for mine project and add mine device node in this .dts file (if it is not there) and it will work?
Please suggest and correct me.
I agree with the #sawdust's comment. Please find the pictorial representation of the same.
I have shamelessly copied it from the presentation here.
To answer your question, you should create your own ".dts" file which includes all the necessary parents (i.e. SOC specific and needed) dtsi files. And compile your ".dts" file using DTC compiler (either from linux/scripts/dtc/dtc in Linux Source tree or by using the package like "device-tree-compiler").
In most cases you can modify the existing device tree file and re-compile it for your purpose. For your case, I think you can have to modify this zynq-zed.dts.