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

Wolfgang Denk wd at denx.de
Tue Aug 23 22:24:04 CEST 2005


In message <200508231047.37928.bwaite at 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Prepare for tomorrow -- get ready.
	-- Edith Keeler, "The City On the Edge of Forever",
	   stardate unknown




More information about the U-Boot mailing list