In message 200508231047.37928.bwaite@irobot.com you wrote:
Why does *u-boot* want the FLASH in a writeable state? Some boards may want
This has already been explained before: to provide a consistent user interface across as many systems as possible (i. e. all those without special requirements).
FLASH in a writeable state, some command lines may want FLASH in a writable state, but u-boot does not need FLASH in a writeable state to boot.
Indeed. So what are you trying to proof?
Would you call it a policy of u-boot not to change the state of hardware in common code unless it is needed to run u-boot? Ie many cpu features are not
No. We do many things that are not strictly needed to run U-Boot, for several reasons.
enabled by default in u-boot. Would changing the powered up state of the FLASH be considered a deviation of this policy?
See above.
Because in the general case (and this is what cfi_flash is used for) you don't expect to have any hardware protected sectors. Not in U-Boot, and neither in Linux when you for example want to use these for a writable MTD partition.
In the general case, if I lock my FLASH to protect a Linux kernel I have there I have explicitly locked that region and I do not expect anyone to unlock it for me.
This requires that your flash chips supports hardware locking in the first place, which is not ger=nerally the case, so your "general case" is not so much general. I think I explained this before. Please re-read my posting.
You should change that in the board package. I do not consider this magic if I have spec-ed the FLASH part for my board because of this feature. I consider it software magic to undo a a feature I designed in.
If you have this requirement, then please feel free to implement it in your board specific driver. I wrote this before, too.
Another implimentation detail would be the additional time needed to unprotect the FLASH at each powerup. On my board, with 64 MB of FLASH, you would be adding ~2 seconds to the u-boot boot time by unprotecting the FLASH. I would then need to waste ~1.5 seconds re locking most of my FLASH. (I only provide write access to a small portion of the 64 MB). Your policy will add almost 3.5 seconds to boot time.
Arghh... it is *obvious* that the one-size-fits-all approach cannot work. If you don't like it, don't use it.
Best regards,
Wolfgang Denk