Imx6ull: flashing u-boot from u-boot?


For a bunch of reasons, I do not want to use T.E.I. for updating my custom bootloader.
One of the reasons is that my company already has the infrastructure and update scripts of other imx products, using the recovery mode on otg, and we are happy with that.
So I would like to flash u-boot from u-boot, assuming this is possible simply using “nand write”.
I do not want to boot a linux for that.
Is there a detailed procedure ? What is the write offset for uboot.img ?
A related question is mx6ull-bcb. Is this mandatory ? Or can I live without it ?

Thanks !

Hi @tbultel,

Not sure about that 1g emmc version, but the 256 and 512kb seem to come with a nand partitioning scheme having a “u-boot1” and “u-boot2” partition. We are able to update uboot using something like:

tftp ${loadaddr} ${ubootimage} && nand erase.part u-boot1 && nand write ${loadaddr} u-boot1 ${filesize} && nand erase.part u-boot2 && nand write ${loadaddr} u-boot2 ${filesize}

You’ll have to set your loadaddr and ubootimage vars for your system of course. There could be some more robustness added here of course also.

Now if toradex elects to change that partitioning/naming scheme, all bets are off :wink:


– Dave

Hi @DaveM ,

thanks for your reply. Yes the NAND version has u-boot1 & u-boot2 in its partition scheme.

For information, u-boot mainline comes with an update script, (update_uboot) that basically perform
the tftp, erase and flash actions.
But this does not work. After flashing u-boot.imx, the board enters recovery mode (independently of
the boot pins selection).

After having spent some time looking for a solution, I first came to this, about imx7:

This is about ixm7, but that teaches us that there are some special work to perform on the uboot image, especially when HAB is activated (this is not my case), but also something about padding the beginning
of image prior to flashing to NAND. That did not help at all, same result.

Later in the day, I came across to this (quite old) discussion:

Basically, I was not the alone in the world, wanting to flash things from u-boot.
And there was a suggestion to use this patch:

This brings the logic of kobs-ng in uboot.
And this worked; I was finally able to boot from flash.

I hope that discussion will not be closed, at the present time.
The patch I used is not on mainline, and will unlikely be merged without some
needed cleanup.
Maybe the answer is in I would like to spend more time,
to understand if I really need the kobs-ng patch or not.
But in whatever case, now that I know that a solution exists, why does Toradex not provide
either a patched u-boot, or uboot post-build script to fix the .imx image, instead of
imposing the T.E.I. to users ? kobs-ng is the only reason to have to boot a linux to flash u-boot ??
I cannot believe that.

I wish we had more feedback / help from Torarex support. I do not see the point
of T.E.I., and Toradex Control Block … All these manufacturer-specific stuff do not help
at all, and since the beginning of the project, have made be lose more time than expected.


Hi @tbultel,

Sorry for the silly answer then…I didn’t know you were so far into it :wink:

Are you patching the uboot sources from toradex or grabbing mainline uboot and modifying? Seems like that first partition mx6ull-bcb might contain that meta-information described in those reference docs? Is there any logic in the toradex uboot sources to reference that area?

Do not worry Dave,

it was not a silly answer, and at this step that is good to my mood to have someone to talk to, I mean, something different than a “> /dev/null” effect :slight_smile:

I definitively want to use u-boot mainline, yes. I have not spent to much time to try to dig in the toradex sources. Maybe later, when I have time.
Meanwhile, I have been able to use imx_usb to flash u-boot from u-boot, without using the console
or interacting with the board.
I am currently in the process of flashing the ubifs volumes, hopefully there is no more specific stuff
to deal with !

Cheers !

As fyi, our process redoes the ubi partitioning scheme of that last mtd partition to add redundant kernel/dtb/rfs partitions and then writes those using tftp (along with updating both uboot mtd partitions).

I do use the toradex uboot sources as our base, so I guess all of that bcb “stuff” just gets magically resolved for me. I doubt just updating the uboot paritions with new code is really the “right way” to do things, but it seems to work :wink:

Like you, the tezi stuff presented (and presents) a bunch of hurdles, but moving to a new development environment (toradex/yocto) always makes you think about how to move from your “old” environment. “old” = very familiar and working just fine, “new” = maybe a good thing and will include most support but could be learning curve. No boss likes to hear “getting up to speed” on anything…

Good luck!

– Dave

Hello @tbultel, I’m glad you managed to write your u-boot using your own procedure. @DaveM, thanks for helping out!

I would just like to clarify some things regarding the use of Toradex Easy Installer.
Toradex Easy Installer comes preinstalled on all Toradex modules and provides an easy way for users to try the demo images that we have available on our feed. This creates an environment where anyone can easily start using the modules and checking what they have to offer, but also gives the user choice about what to install.

However, Toradex Easy Installer is not just that. It provides tools to help customers to execute factory programming tasks on our modules. It is capable of unattended auto-installing images from external media (SD-cards, USB sticks) and also from ethernet, where you can provide the feeds for the images you build.

Our customers are not required to use it (as you already found out!) but we are confident that in most cases the easy installer would be the best approach. Here are some reasons for that:

  • Toradex modules have a pretty long supported lifespan. During the supported lifetime of the products, sometimes HW changes are necessary (there are a lot of examples happening right now because of all the supply chain difficulties). Toradex will work hard to make sure that your modules keep being delivered, and that the easy installer will keep working on the delivered modules.

  • Toradex module families provide upgrade paths inside them, sometimes with no HW changes. At the moment this advantage may not seem like a big deal because most of our offerings are within the NXP family, but this was not always the case. On the Colibri family you could migrate from an NXP IMX6 to an Nvidia T30 for instance, and if using the easy installer your factory programming wouldn’t need to change very much (just generate the proper image for the new module and the easy installer will take care of installing it).

In the end, the easy installer is a tool that allows the customer to worry about installing the images on the modules on a slightly higher level, while the low level bits are taken care by Toradex.

Here is the link to the easy installer manual where you can see a complete list of the features:

I hope this helps,