...

Is there a way to ensure the correctness of U-boot in the flash (e.g.

CRC)?

assuming it isnt memory mapped, read it into ram and use the crc command ? if it is memory mapped, then just use the crc command ...

Yes of course I can do that. My question was if there was a way (or a plan) to embed this CRC in the U-boot image, otherwise I'd have to burn it elsewhere (in another sector for instance).

David.

...

Yes of course I can do that. My question was if there was a way (or a

plan)

...

to embed this CRC in the U-boot image, otherwise I'd have to burn it elsewhere (in another sector for instance).

The environment is a convenient place, unless your environment is embedded within U-Boot, in which case you need to split this up anyway.

Won't work in our case I'm afraid. First, we would like the booted application to be able to check the CRC after upgrading U-boot, which means that it will need to know the environment structure (something that is also problematic legally, as some of our applications are non GPL). Second, our master plan is to have two copies of U-boot programmed on the flash (for field upgrades sake), with a mutual environment sector. I guess the only way to implement this meeting our requirements is to sacrifice an adjacent sector that will only hold the CRC. Best regards, David.

I don't understand why this should be a problem. Reading the environment can be done by separate tools lile fw_printenv (see tools/env/).

Can I use it in non-GPL apps as well? Anyway as I mentioned before, storing the CRC in the environment isn't suitable for us anyway.

So you have some primary bootstrap loader which performs the selection and switching? Well, sounds overly complicated to me, but it's your choice.

This is one option, but I don't like it because it's cumbersome indeed. This is actually the implementation in our older (non U-boot) boards. Another option we consider is to have two initially identical copies of U-boot in the flash, say U-boot1 & U-boot2, where U-boot1 is considered to be the non upgradeable boot, and U-boot2 is the upgradeable one. At an early stage of U-boot1 (say board_init_f), it checks the CRC of U-boot2, and if ok, it branches there (otherwise it continues as usual). This way, in most of the cases U-boot2 is the "active" booter, and U-boot1 is only used for failsafe purposes. It's just an idea at this stage though.

Why don't you enable the MD5 checksum feature then? It uses an embedded (in the image) MD5 checksum.

Sorry - searched throughout the code and documentation, and couldn't find anything on MD5 checksum. Would appreciate more details.

Regards, David.

You couldn't find it, because I confused that ;-)

It's a SHA1 checksun what's being used. See doc/README.sha1

Thanks. Seems like what I need exactly. Best regards, David.