u-boot kernel command line

[gauthier]

I am trying to modify the kernel command line of a yocto image I built.

I baked a core-image-x11 image and put it on my SD card with dd. The imx6q_sabresd booted fine so I went on and made it take its rootfs from NFS. To achieve that I manually changed the u-boot variables with setenv and saveenv.

Now that this is working, I would like to change my yocto build itself so that the kernel command line gets its correct parameters without me doing it manually.

I cannot find how to do this.

The Kernel Development Manual

http://www.yoctoproject.org/docs/1.6.1/kernel-dev/kernel-dev.html

says at the bottom:

" How do I change the Linux kernel command line?

The Linux kernel command line is typically specified in the machine config using the APPEND variable. For example, you can add some helpful debug information doing the following:

     APPEND += "printk.time=y initcall_debug debug""

but this is not very helpful. Where do I add this exactly?

Where are my current u-boot parameters defined? What is the best way to make changes to them?

Here is what I tried:

- I went to the machine config (as per the doc above) there: sources/meta-fls-arm/conf/machine/include, but I did not find where in there I should put the APPEND.

I also tested to modify sources/meta-fls-arm/conf/machine/include/imx6sabresd-common.inc (changing ttymxc0 only to see if that would get through to the final image) but it had no positive effect. The kernel command line did not change, and it did break the startup. Nothing happens after:

"Starting Linux NFC daemon

Stopping Bootlog daemon

INIT: Id "mxc6" respawning too fast: disabled for 5 minutes

"

- I noticed several patch files there: sources/meta-fls-arm/recipes-bsp/u-boot/u-boot-imx/, but first I am not sure how bitbake sorts out which one to apply, second the u-boot parameters I end up with are not the ones in the relevant patch (mx6q_sabresd-*.patch).

Furthermore, the patch is on the file include/configs/mx6q_sabresd.h. I have no such file, not that I could find at least. Is the patch even being applied, how can I check this? And where is it applied, in that case?

It feels like I am making wrong assumptions, if anyone could shed a light...

[jamesbone]

If the answer from Leonardo ,answers your question, please click the Correct Answer button. Thank you!

Have a great day,
Jaime

[LeonardoSandova]

On U-boot source code, You can modify the default environment variables on the configuration header file. For example, for a sabresd board, you may want to change the CONFIG_BOOTCOMMAND defined on include/configs/mx6sabre_common.h

[gauthier]

Thanks for the answer.

Short version of what I still have troubles with:

Modifying the source file in tmp/work/.../git worked, but I want to make the change stay. I have attempted patches but I can't seem to make it work.

I *think* that working with patches is the correct workflow, is that correct? How would you do it?

--- detailed version ---

I modified

"build/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-fslc/v2014.01-r0/git/inlude/configs/mx6sabre_common.h", to add a string to CONFIG_EXTRA_ENV_SETTINGS, netboot:

- "netboot=echo Booting from net...; " \

+ "netboot=echo Booting from net DO I SEE THIS?...; " \

After this I recompiled u-boot:

build $ bitbake u-boot -c compile -f

Which resulted in:

NOTE: Preparing runqueue

NOTE: Tainting hash to force rebuild of task /home/gauthier/numpy-fsl-community-bsp/sources/meta-fsl-arm/recipes-bsp/u-boot/u-boot-fslc_2014.01.bb, do_compile

NOTE: Executing SetScene Tasks

NOTE: Executing RunQueue Tasks

NOTE: Tasks Summary: Attempted 214 tasks of which 213 didn't need to be rerun and all succeeded.

Then I uploaded the .sdcard file to my SD card, stopped the boot at the u-boot prompt, and "print" gave:

netboot=echo Booting from net ...; run netargs; if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; ${get_cmd} ${uimage}; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if ${get_cmd} ${fdt_addr} ${fdt_file}; then bootm ${loadaddr} -

...

The change did not make it. What was wrong is that I only rebuilt u-boot, and didn't regenerate the image. After a:

build $ bitbake core-image-minimal

and a new upload, the command was updated!

This is great, but the manual changes will disappear the next time I sync the repo, or at the next clean.

I understand from the doc (Yocto Project Development Manual) that I have to make a patch, but I do not find the information there precise enough for me. What is the best practice to create a patch for this file, and make sure the patch is applied at the next build?

Is the following workflow acceptable, or should it be different:

- make changes in build/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-fslc/v2014.01-r0/git/

- test with recompiling the module (-c compile -f) and regenerating the image

- when it works, commit with "git commit -a --sign-off" and a meaningful message

- create a patch with the new work, with "git format-patch -1" (or whichever number of commits)

- copy the new .patch file(s) to sources/meta-fsl-arm/recipes-bsp/u-boot/u-boot-imx/.

- regenerate the whole image (I tested that the patch was applied by modifying the copied .patch file by hand before generating)

-> the old string ("DO I SEE THIS?") was still there. The patch was not applied.

I tried to force rebaking u-boot with:

build $ bitbake u-boot -f

but the file git/include/configs/mx6sabre_common.h was untouched by the patch.

I tried copying the .patch file to mx6sabre_common.patch, it did not help.

(I have no idea why this topic was made "Assumed Answered")

[gauthier]

This chapter was much more helpful: http://www.yoctoproject.org/docs/1.3/dev-manual/dev-manual.html#using-a-git-workflow

I missed to add the patch in the recipe:

SRC_URI += "file://0001-<commit-summary-message>.patch"

After doing this, the patch was applied, and the mx6sabre_common.h file in /tmp/work/.../git showed the new string ("IS THE PATCH APPLIED?").

I bumped the PV number in the recipe (v2014.02 instead of v2014.01), so the new mx6sabre_common.h file was placed in another directory structure, in  a v2014.02-r0. Should I have created a PR = "1" in the recipe instead? Or something else? What do people usually do in such cases?

I regenerated the image, uploaded to the SD card, and... that worked!

So now I have something that works and should survive rebuilds.

I would appreciate a confirmation that this is the way to do things, or if there is a better, more common, easier, whatever way.

[LeonardoSandova · Accepted solution]

Gauthier,

you did the right steps. The only point you can improve is to create a new layer, and on this layer create a bbappend file, which is a recipe patch. Inside this, add the patch the way you did it (SRC_URI += "...."). All these steps are a bit complicated a the beginning, but this is the yocto way to do stuff.

There are many tutorials out there, check the official ones, specially the dev manual.