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

[Wolfgang Denk]

Dear Ravi Shekhar,

In message <OF467D8790.9D3F5260-ON652576B6.00303B47-652576B6.002FF4E7 at 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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The flow chart is a most thoroughly oversold piece of  program  docu-
mentation.              -- Frederick Brooks, "The Mythical Man Month"