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.