[U-Boot-Users] [PATCH] cfi_flash.c patches

[Brian Waite <bwaite@irobot.com>]

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.