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