Wolfgang Denk writes:
...
Wolfgang> Not for me. I don't like the hardware doing magic things Wolfgang> to me. I want to be in control over the hardware - not Wolfgang> vice versa.
Tolunay> While you see it important to protect U-Boot environment Tolunay> (for various reasons and I agree), you do not seem to Tolunay> consider consistent protection for another area of flash Tolunay> that may be storing equally vital information for software Tolunay> system. Why?
Wolfgang> Not on a *automatic* base. I accept this only if Wolfgang> explicitely requested by the user (by using the "protect Wolfgang> on" command) *and* the board designer (by providing a Wolfgang> flash implementation that supports hardware write Wolfgang> protection both in hardware [by selcting appropriate flash Wolfgang> chips] and in software [by enabling the needed features in Wolfgang> U-Boot]).
...
There are two main types of Intel flashes (AMD/Spansion do not provide software-controllable hardware protection): flash files (uniform sectors) and boot blocks. The former come out of reset unprotected, the latter - protected. If the above mentioned board designer chooses to use a boot block, he/she selects flash which is protected by default. If U-Boot must automatically change this behaviour, why to use such a flash in the first place? Regarding the implementation, unprotecting the flash on U-Boot's start up requires exactly the same operations as implemented in the flash_real_protect function (which is controlled by CFG_FLASH_PROTECTION) so IMHO the same function must be used for automatic unprotection too to avoid code duplication though I agree with Tolunay that defining CFG_FLASH_PROTECTION and calling "protect off" is the way to go.