Invalid Choice: 'Kernel_Add_Dts' in Yocto Build

invalid choice: 'kernel_add_dts' in yocto build

Use recipetool to add a new device tree to your custom layer following this syntax:

recipetool appendsrcfile -wm (MACHINE) (PATH/TO/LAYER) virtual/kernel (PATH/TO/DTS) 'arch/${ARCH}/boot/dts/(YOUR_DTS_NAME).dts'

Details:

• (MACHINE): Your build machine name
• (PATH/TO/LAYER): The path to the layer that you want the linux-xx_%.bbappend file with the new DTS will be created
• (PATH/TO/DTS): The path to the new DTS file
• (YOUR_DTS_NAME): The DTS file name

Important note:

If the default device tree name is the same as the one you are adding it is not a problem, if not, please make sure that you add it to KERNEL_DEVICETREE variable so that it will be shipped with all the DTS files in the boot partition.

KERNEL_DEVICETREE += "(NEW_DTS_NAME).dtb"

After that you can stop Uboot (if you are using Uboot) and specify the new DTS file with:

setenv fdt_file (NEW_DTS_NAME).dtb
saveenv (If you want to save it for every boot)

Please run "printenv" to make sure of the "fdt_file" variable's name.

Real run test:

recipetool appendsrcfile -wm imx8mmddr3lval /home/talel/Desktop/final_git/meta-node virtual/kernel /home/talel/Desktop/example.dts 'arch/${ARCH}/boot/dts/example.dts'
...
NOTE: Writing append file /home/talel/Desktop/final_git/meta-node/recipes-kernel/linux/linux-imx_%.bbappend
NOTE: Copying /home/talel/Desktop/example.dts to /home/talel/Desktop/final_git/meta-node/recipes-kernel/linux/linux-imx/imx8mmddr3lval/example.dts

The new bbappend file is:

$ cat /home/talel/Desktop/final_git/meta-node/recipes-kernel/linux/linux-imx_%.bbappend

SRC_URI += "file://example.dts;subdir=git/arch/${ARCH}/boot/dts"

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

PACKAGE_ARCH = "${MACHINE_ARCH}"

With "virtual/kernel" it will detect what provides it (linux-imx, linux-yocto, ...) and it will create linux-imx_%.append file.

The -w flag will create "_%" as for any version number.

Solution to avoid any patch for the DTS file:

If there is patches for your Linux kernel they will fail if you are updating the DTS with new modifications that override some lines that the patch expects, so you can do it cleanly in 2 ways:

bitbake virtual/kernel -c cleansstate
bitbake virtual/kernel -c patch

Now all patches are applied, go to tmp/work/../linux-(PROVIDER)/../git and:

git add .
git commit -m "commiting old patches"

Now edit the DTS file and:

git add arch/../boot/dts/../myplatform.dts
git commit -m "changes"
git format-patch -1 -o /path/to/meta-custom/recipes-kernel/linux/files

Now add it to /path/to/meta-custom/recipes-kernel/linux/linux-(PROVIDER)_%.bbappend:

SRC_URI_append = " file://patch_file.patch"

Or, the other way is to add your final DTS after the patch is done:

SRC_URI_append = " file://myplatform.dts"
do_configure_append(){
  cp ${WORKDIR}/myplatform.dts ${S}/arch/(ARCH)/boot/dts/....
}

and copy your myplatform.dts to /path/to/meta-custom/recipes-kernel/linux/files.

Now, that's your final DTS file.

Remove what recipetool added:

Actually, no undo subcommand in recipetool, you just need to delete the files that recipetool deployed, recipetool copy the file you specified and create a bbappend file, so remove those two files.

Example: you used recipetool to add example.dts file, recipetool copied example.dts to:

meta-custom/recipes-kernel/linux/(MACHINE)/example.dts

and created bbappend file in which it added example.dts to SRC_URI variable.

If you need to keep the bbappend file because you are using it in other way, just modify it and remove the line added by recipetool which contains:

SRC_URI ... "file://example.dts ..."

user space and device tree recipe combined in yocto build

KERNEL_DEVICETREE variable is used to specify the device tree files that need to be generated and added to the boot partition, but the bootloader will only charge one of them in the RAM while booting.

Example, for U-boot, the file specified in DEFAULT_FDT_FILE in the board's defconfig file will be used. But you can change the DTB by pausing U-boot and specifying the DTB file with:

setenv fdt_file new_file.dtb (make sure of "fdt_file" var with "printenv")

You can use recipetool to automatically add your new device tree file to your linux recipe, check my answer here.

You don't have to compile the DTS separatly, because adding it to KERNEL_DEVICETREE variable will cause it to be shipped in the boot partition.

Any modifications on the Linux kernel can be added into :

meta-custom/recipes-kernel/linux/linux-(PROVIDER)_%.append

the (PROVIDER) could be found in the machine configuration file, and it is a provider for virtual/kernel recipe.

You create patches for your Linux, go to:

tmp/work/.../linux-(PROVIDER)/../git

do your edits and:

git add modified_file
git commit -m "updates"
git format-patch -1

This will generate a "updates.patch" file, that you can add it to linux-(PROVIDER)_%.append file:

SRC_URI += "file://updates.patch"

Make sure you copy the patch file to:

meta-custom/recipes-kernel/linux/files

Now, the Linux build will triggered and apply the patch.

Multiple configuration build in yocto

From what you describe you are looking for UBOOT_CONFIG.

You could do the following in your single machine configuration:

UBOOT_CONFIG = "abc def xyz"
UBOOT_CONFIG[abc] = "ubootconfig1_defconfig"
UBOOT_CONFIG[def] = "ubootconfig2_defconfig"
UBOOT_CONFIG[xyz] = "ubootconfig3_defconfig"

See: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-UBOOT_CONFIG

Quick rebuild of device tree only with Yocto/bitbake?

AFAIK there are two different ways of doing this.

1. The kernel way: Using the scripts provided by the kernel

• Change to your kernel source directory (<build dir>/tmp/work/<machine>/<kernel-name>/<kernel-version>/git/)
• Execute the device-tree-compiler: ./scripts/dtc/dtc -I dts -O dtb -o ./devicetree.dtb path/to/devicetree.dts

2. The bitbake way: Using the kernel's deploy job

• Call $ bitbake <kernel-name> -f -c deploy
• The generated device-tree-blob then can be found in <build dir>/tmp/work/<machine>/<kernel-name>/<kernel-version>/build/arch/arm/boot/dts/)

At least for me both versions worked in a quick test.

UPDATE:
I just came over a third version of building the dtb with yocto on the net.
That one uses yocto's devshell of the kernel build.
For more information see the original authors page at https://splefty.blogspot.co.at/2015/09/compiling-device-tree-using-yocto.html.

How to bind a kernel patches to different recipes

Similar != identical. If they are indeed slightly different, then two machines is the way to go. If they are sufficiently similar (to be determined by yourself :) ), different distros is also an option. All depends on how different the machines are and how different the final images should be (might need two machines or two distros or both).

If you have two similar machines but need two machine configuration files, put most of the common code into an .inc required by both machines. Don't forget to put a MACHINEOVERRIDES somewhere in that inc file with a name that will make sense for both machines (e.g., if you have rpi3-lcd and rpi3-iot, have an rpi3-common.inc with rpi3-common added to MACHINEOVERRIDES). This will make it possible to use VAR_rpi3-common in recipes that have patches or machine specific stuff in your recipes to apply to both without needing VAR_rpi3-lcd AND VAR_rpi3-iot.

How to change the config of u-boot in Yocto

Technically the process you described sounds correct to me. But there's a couple of obstacles to watch out for, respectively things to check:

1. is your .bbappend actually processed?

While this seems to be the case for you (you found out through the debug output) this is usually easier checked with:

bitbake-layers show-appends

This will give you a complete and detailed list of all appends that are in effect in your current build situation.

2. Does the .bbappend actually have the desired effect?

If more than one recipe is involved, things can be complicated, and overwrite each other. Check with

bitbake -e u-boot-imx

to see what actually happens. This is best combined with piping into less (or the pager of your choice) and then searching for the modified values, like SRC_URI.

3. Find out what your u-boot machine is.

Given the information from 2., this is rather trivial: check for the variable called

UBOOT_MACHINE

as this is what u-boot really should see.

4. Try to not tell bitbake what to do it too much detail.

Especially combining the -f and -c switches might have unexpected results, as you basically tinker with the task dependencies. In my experience, something along

bitbake -c clean u-boot-imx && bitbake u-boot-imx

should work better, as it goes through the whole build dependency, including configuration, patching, and so on.

EDIT / ADDENDUM

I've checked with the OE devs, and the main problem is that the defconfig mechanism is (linux-)kernel specific, thats also why it is explained in the kernel-dev manual.

So to get your config into the actual build, there are one and a half solutions.

1. The correct way:

Prepare a patch to the u-boot sources. In your case, thats probably just a minor modification to the defconfig file that already is in use. Have the patch in the canonical format and add it to SRC_URI, then it should automatically be picked up and do the trick.

2. The hackish (and untested, therefore only half) way:

Prepare your config in full format (not the defconfig stripped down version). Then add it to SRC_URI and use it through an additional task in your .bbappend:

do_compile_prepend() {
  cp YOURFILENAME ${S}/.config
}

This should inject the new configuration directly before compilation starts. It might need a little tinkering, but you certainly get the idea. Another approach would be to inject your defconfig over the original file.

Having said that, I strongly recommend the first way.

Modifying the device tree for the Beaglebone Black

So I got this working by taking my device tree blob, decompiling it, and merging in sections from the device tree overlay files, and recompiling. I realized I needed uarts 1 and 2 instead of 2 and 4, so this is slightly different than my original problem.

To decompile the device tree blob:

dtc -I dtb -O dts -o am335x-boneblack.dts am335x-boneblack.dtb

I used the existing uart0 as an example to show me the right sections to work in.

I added a section for uart1 and uart2 in the pinmux section under the section for uart0. It now looks like this:

pinmux_uart0_pins {
    pinctrl-single,pins = <0x170 0x30 0x174 0x0>;
    linux,phandle = <0x27>;
    phandle = <0x27>;
};

bb_uart1_pins: pinmux_bb_uart1_pins {
    pinctrl-single,pins = <
        0x184 0x20 /* P9.24 uart1_txd.uart1_txd  OUTPUT  */
        0x180 0x20 /* P9.26 uart1_rxd.uart1_rxd  INPUT  */
    >;
};

bb_uart2_pins: pinmux_bb_uart2_pins {
    pinctrl-single,pins = <
        0x150 0x21  /okay* spi0_sclk.uart2_rxd | MODE1 */
        0x154 0x01  /* spi0_d0.uart2_txd | MODE1 */
    >;
};

Then later, the serial sections need to be enabled and told what pins to use. I modified existing uart sections, and it now looks like this:

serial@44e09000 {
    compatible = "ti,omap3-uart";
    ti,hwmods = "uart1";
    clock-frequency = <0x2dc6c00>;
    reg = <0x44e09000 0x2000>;
    interrupts = <0x48>;
    status = "okay";
    dmas = <0x26 0x1a 0x26 0x1b>;
    dma-names = "tx", "rx";
    pinctrl-names = "default";
    pinctrl-0 = <0x27>;
};

serial@48022000 {
    compatible = "ti,omap3-uart";
    ti,hwmods = "uart2";
    clock-frequency = <0x2dc6c00>;
    reg = <0x48022000 0x2000>;
    interrupts = <0x49>;
    status = "okay";
    dmas = <0x26 0x1c 0x26 0x1d>;
    dma-names = "tx", "rx";
    pinctrl-names = "default";
    pinctrl-0 = <&bb_uart1_pins>;
};

serial@48024000 {
    compatible = "ti,omap3-uart";
    ti,hwmods = "uart3";
    clock-frequency = <0x2dc6c00>;
    reg = <0x48024000 0x2000>;
    interrupts = <0x4a>;
    status = "okay";
    dmas = <0x26 0x1e 0x26 0x1f>;
    dma-names = "tx", "rx";
    pinctrl-names = "default";
    pinctrl-0 = <&bb_uart2_pins>;
}

To recompile the device tree:

dtc -I dts -O dtb -o am335x-boneblack.dtb am335x-boneblack.dts

In short, I managed to get this working despite having little to no idea how device trees work.

I also needed to disable hdmi which I did by setting status equal to "disabled" in the hdmi section.

yocto defconfig not found

You have your defconfig file in a directory called myCustomRecipe_3.16/, while OpenEmbedded will look for the file in directories(1) named either of:

• myCustomRecipe-3.16/
• myCustomRecipe/
• files/

Note the '-' instead of '_'.

If you look at the log.do_unpack for your failed recipe, you'll see which directories has been searched for your defconfig.

(1) Well, that's only part of the story. Those three directories will be appended with directories for all your OVERRIDES as well.

---

Related Topics