On Monday 22 August 2005 6:46 pm, Wolfgang Denk wrote:
Just a couple of emails ago you were saying all sectors should be in writable state in U-Boot. This is a policy which is announced today by you.
OK.
Why does *u-boot* want the FLASH in a writeable state? Some boards may want 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.
Leaving the state of sectors (except for U-Boot managed sectors) until user takes explicit lock/unlock action as they are is another policy .
I don't call this a policy.
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 enabled by default in u-boot. Would changing the powered up state of the FLASH be considered a deviation of this policy?
Why do you think it is OK for U-Boot to unlock sectors/blocks that it knows nothing about their usage? Wouldn't leaving these sectors in a
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.
safer state a common sense approach?
Not for me. I don't like the hardware doing magic things to me. I want to be in control over the hardware - not vice versa.
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.
While you see it important to protect U-Boot environment (for various reasons and I agree), you do not seem to consider consistent protection for another area of flash that may be storing equally vital information for software system. Why?
Not on a *automatic* base. I accept this only if explicitely requested by the user (by using the "protect on" command) *and* the board designer (by providing a flash implementation that supports hardware write protection both in hardware [by selcting appropriate flash chips] and in software [by enabling the needed features in U-Boot]).
As mentioned before: if you want to have this on a board, OK, then implement it there and put apropriate big warnings and notes in your board documentation. If this is general code which is used by many boards that you don't control (and do not test!) then I want to provide a common interface. And common behaviour is that flash can be erased and written to in the boot loader.
You cannot tell the difference in the Intel part that was origianlly referenced between sectors locked at reset and sectors explicitly locked. Therfore you are unlocking explicitly locked sectors at the same time.
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.