U-boot customization difficulties

I’m attempting to customize/tweak u-boot on torizoncore and encountering some difficulties.

I’m (reasonably) familiar with yocto/bitbake, etc, and in the past I successfully altered the kernel config to add some drivers and made a new torizoncore image I could then use with tcb without issue.

However, trying to alter u-boot currently has me stumped because it seems to be actively rejecting my changes.

I’ve set up my build environment with 6.2.0, executed devtool modify u-boot, and made some changes to imx8mp-verdin_defconfig in the workspace folder.

However, a subsequent bitbake u-boot simply ignores these changes (as determined by looking at the .config file in the workspace oe_workdir folder.

I’m using this article as my starting point: Splash Screen on U-Boot | Toradex Developer Center
and for sanity am trying to enable DM_VIDEO and CMD_BMP.

I’m probably missing something obvious here but I’m not sure what, so I hope someone can point me in the right direction.

(Note that for my testing purposes I’m aware the final image ostree build step will fail because these changes are not committed, but I am currently only focused on getting u-boot to compile properly with my changes before I address that aspect)

Thanks!

Greetings @bw908,

I don’t have too much experience with using the devtool utility in a Yocto build. But, from what I understand devtool modify <recipe> allows you to modify the source of whatever recipe was specified. In which case wouldn’t you need to do devtool modify u-boot-toradex?

The yocto recipe for the Verdin i.MX8M Plus U-boot is this: u-boot-toradex_2022.04.bb « u-boot « recipes-bsp - meta-toradex-nxp.git - Toradex BSP layer, recipes for NXP based modules

Perhaps your changes are not having affect because you’re modifying a recipe by the name of u-boot, which I assume is just a generic U-Boot recipe and not the U-Boot that gets used for our modules.

Best Regards,
Jeremias

It’s possible and I’ll double-check tomorrow, but as far as I can tell devtool considers u-boot a generic name that defers to whatever the distro specifies, for example u-boot-imx or in this case u-boot-toradex.
(and indeed, if I try devtool modify u-boot-toradex, it tells me it’s already checked out)

Note the checked out directory contains the Toradex specific changes if I view its log, which also strongly suggests to me that it is the correct one.

I tried looking up how a devtool based workflow operates to see if I can familiarize myself with the utility and how it works. According to various blogs and posts like these:

It seems like beyond just running devtool modify <recipe> additional devtool commands may be needed for the changes to take effect in the next bitbake. Though I’m not sure how up-to-date or accurate this information is. Personally I just create patches and bbappends to modify an existing Yocto recipe.

Best Regards,
Jeremias

In my past experience devtool modify by itself is enough to allow you to edit the sources for a particular recipie, but yes, other commands are required to formulate them into patches that can be placed in a layer for finalizing your changes the “right” way.

This appears to be a weird quirk of the u-boot setup. I ended up finding this, which is the exact issue I was having:

and it only started working “properly” once I made a custom layer and added a patch to the defconfig. My guess is somewhere in the u-boot recipe pile there’s something either forcing a different config instance or so.

Huh interesting find, well glad you were able to find a solution!

Yep, now I am in the process of trying to patch in the LVDS drivers so that u-boot can display a splash screen as soon as it starts. There are some snippets floating around out there for this but nothing drop-in yet.

To clarify - the above issue only relates to CONFIG_ values in the imx8mp-verdin_defconfig file. The checkout folder generated by devtool has no problems if you make edits to any of the c/dts/h files, those take effect right away without the need for a patch and yocto layer.

A related question: Will there be a TEZI recovery build based off 6.x in the near future? It’s somewhat of a convenient means to test bootloader changes quickly by just building imx-boot and swapping it out in the recovery package, but this only works for the 5.7.x branch right now - doing so with 6.x fails because of the u-boot differences.

I can say we do plan to eventually have a Tezi 6.X, though I can’t provide an accurate roadmap at this time. For reference our upcoming AM62 module is planned to come with a 6.X based Tezi.

Best Regards,
Jeremias

Thanks. For now I just modified my images.json for the deploy to only flash uboot to speed up the test cycle. Then at least I’m not waiting several minutes for a reflash of the entire main partition.