[U-Boot] modifying u-boot image to distinguish between primary and secondary

My board has two boot-loaders namely, primary bootloader and secondary bootloader. however the image file name for both the bootloaders are same, u-boot.bin. Now, I want to make a check before loading u-boot to flash whether its a primary bootloader or secondary bootloader. What i thought is, why not to append primary or secondary string after the version in the uboot..bin but I am not sure how it works. Can anyone please give me some Ideas on this.
Thanks and Regards -- Ravi Shekhar ravi.shekhar@lntemsys.com Embedded Systems and Softwares Mobile:-9620793761
"This time, like all times, is a very good one, if we but know what to do with it."

Dear Ravi Shekhar,
In message OFFE8B8C82.0B75DDB4-ON652576B6.001CDB45-652576B6.001D0D2F@lntemsys.com you wrote:
My board has two boot-loaders namely, primary bootloader and secondary bootloader. however the image file name for both the bootloaders are same, u-boot.bin. Now, I want to make a check before loading u-boot to flash whether its a primary bootloader or secondary bootloader. What i thought is, why not to append primary or secondary string after the version in the uboot..bin but I am not sure how it works. Can anyone please give me some Ideas on this.
You have to be more specific.
Why do both your images have the same file name? Wouldit not besimple enough to rename at least one of them?
I understand the images are different (otherwise changing the version string would not work).
You write "check before loading u-boot to flash" - in this case, how does modifying the version string inside the image help you? You would need a tool to "look inside" the images so it can locate and extract this string.
Assuming you are using U-Boot to load the images and write these to flash, you might create U-Bot images (using mkimage with "-T firmware" and "-O u-boot") and use these. Here it is trivial to assign names to the images, which can easily be extrated (using "mkimage -l" on the command line or "iminfo" in U-Boot).
Or, with a little more effort, but a lot additional flexibility, you could create a single FIT image which holds both your primary and secondary image, so these can be installed in one go.
If I were you I would try the FIT image approach.
Best regards,
Wolfgang Denk

Sorry for not providing with more details. On my board I have a primary (recovery) bootloader and a secondary full-featured bootloader. The primary bootloader is normally not interactive or accessible at startup. The primary bootloader immediately loads the secondary bootloader. If the secondary bootloader is corrupted (its checksum fails) then the primary bootloader will become interactive and place a <RECOVERY-BL> prompt. Normally, I burn primary u-boot image first and then I get a recovery console from where i burn secondary u-boot to flash. Now, My idea was to append some string to the version of the u-boot and some how parse it before loading it then I can distinguish between the two u-boot images. As I am new to u-boot, I wanted to know whether this approach is right or not. This is required only to prevent user from using wrong u-boot image for booting (say, using secondary image instead of primary).
--Ravi
Wolfgang Denk wd@denx.de 01/25/2010 01:53 PM
To Ravi Shekhar Ravi.Shekhar@Lntemsys.com cc u-boot u-boot@lists.denx.de Subject Re: [U-Boot] modifying u-boot image to distinguish between primary and secondary
Dear Ravi Shekhar,
In message OFFE8B8C82.0B75DDB4-ON652576B6.001CDB45-652576B6.001D0D2F@lntemsys.com you wrote:
My board has two boot-loaders namely, primary bootloader and secondary bootloader. however the image file name for both the bootloaders are
same,
u-boot.bin. Now, I want to make a check before loading u-boot to flash whether its a primary bootloader or secondary bootloader. What i thought
is, why not to append primary or secondary string after the version in
the
uboot..bin but I am not sure how it works. Can anyone please give me
some
Ideas on this.
You have to be more specific.
Why do both your images have the same file name? Wouldit not besimple enough to rename at least one of them?
I understand the images are different (otherwise changing the version string would not work).
You write "check before loading u-boot to flash" - in this case, how does modifying the version string inside the image help you? You would need a tool to "look inside" the images so it can locate and extract this string.
Assuming you are using U-Boot to load the images and write these to flash, you might create U-Bot images (using mkimage with "-T firmware" and "-O u-boot") and use these. Here it is trivial to assign names to the images, which can easily be extrated (using "mkimage -l" on the command line or "iminfo" in U-Boot).
Or, with a little more effort, but a lot additional flexibility, you could create a single FIT image which holds both your primary and secondary image, so these can be installed in one go.
If I were you I would try the FIT image approach.
Best regards,
Wolfgang Denk

Dear Ravi Shekhar,
In message OF467D8790.9D3F5260-ON652576B6.00303B47-652576B6.002FF4E7@lntemsys.com you wrote:
Sorry for not providing with more details. On my board I have a primary (recovery) bootloader and a secondary full-featured bootloader. The primary bootloader is normally not interactive or accessible at startup. The primary bootloader immediately loads the secondary bootloader. If the secondary bootloader is corrupted (its checksum fails) then the primary bootloader will become interactive and place a <RECOVERY-BL> prompt. Normally, I burn primary u-boot image first and then I get a recovery console from where i burn secondary u-boot to flash. Now, My idea was to append some string to the version of the u-boot and some how parse it before loading it then I can distinguish between the two u-boot images. As I am new to u-boot, I wanted to know whether this approach is right or not. This is required only to prevent user from using wrong u-boot image for booting (say, using secondary image instead of primary).
I have to admit that I consider the concept overly complicated. If you allow updating U-Boot in the field, including the primary image, then you don't gain much of additional robustness compared to the added complexity. But that's your design and your decision, of course.
And yes, of course you can add all sorts of non-standard bells and whistles to your systems, including parsing internal strings in the image files.
But I would not recommend doing this. Instead, I recommend to stick with ready available standard features.
And as mentioned before, there are at lkeast two that allow to implement such a szenario:
- using "U-Boot" firmware images is simple and straightforward; even if you might have to add code to acess the name field of the image header, at least you are using a documented standard interface, and you can refer to existing code
- using a FIT image is even more powerful and elegant; this is what I would do
Best regards,
Wolfgang Denk
participants (2)
-
Ravi Shekhar
-
Wolfgang Denk