U-Boot policy on flash protection (was [U-Boot-Users] [PATCH] cfi_flash.c patches)

Detlev Zundel dzu at denx.de
Fri Aug 26 16:12:39 CEST 2005


Hi Tolunay & all board maintainers,

> Wolfgang Denk wrote:
>
>>> I think it is wrong for U-Boot to make any abstraction on any
>>> portion of flash that it does not know anything about it's use. The
>>> tools available today within U-Boot provides all the necessary and
>>> sufficient facilities to deal with any usage model.
>> Right. The discussion is just what the  default  configuration  shall
>> look like, and I get tired of pointing this out again and again.
>
> You are thinking that the default configuration you have chosen for a
> common driver is "mainstream" and more common than not and I an not so
> sure about it. My experience is pointing to the opposite. I think
> "common" default configuration should be covering as many cases as
> possible rather than shrink the potential application of a common
> driver.

To be honest, I share your point of view in this respect but to
convince Wolfgang, more of the maintainers have to speak up.

In private communications it turns out that Wolfgang weighs in years
of experience added to the technical question so the board maintainers
have to come up with sufficient proof that this really is a point
where a consensus has to be reached.

As one example note the Linux MTD subsystem which (as I gather) still
has some problems with hw protected chips - so unprotecting all flash
in U-Boot makes live easier for those using MTD.

To sum up my point again - I don't see any "wrong" or "correct"
solution - I simply feel that the current U-Boot policy of using a
least common denominator doesn't anymore fit what we see today.

> Deviation from your chosen "default" will mean more  board designers
> will need to duplicate cfi_flash.c and have maintain fixes/changes
> introduced to cfi_flash.c separately. This is back to the time where
> there were many flash.c in board directories where each had 90% common
> code.
>
> To solve this, I guess we will need more hooks (increase
> configurability) into this common driver so we can override the
> behavior of cfi_flash.c from board directories and prevent code
> duplication. I hope you would not object to this as long as the code
> size for other boards would not be increased.

This is actually a very strong point - Wolfgang speculates that most
of the board ports will only make use of the "standard" behaviour of
the flash driver so that in the end he ends up with a broad range of
systems working alike.  If many porters are going to deviate from this
standard then the situation changes fundamentally and it then would
make sense to adapt a different policy so that more boards work alike.

So in the end it is a question of what the board maintainers will
choose - if many deviate by including board specific code then
Wolfgang will surely reconsider his position.  If not too many people
care then things will stay as they are.  So its up to the people here
on this mailing list - speak up if you want your opinion to be heard.
And by the way - don't forget to consider the "user" of U-Boot also.
Sometimes things being pleasant for U-Boot porters make life
unneccessary hard for them.

Ok, my vote goes for not trying to abstrace the hw protection of flash
chips in U-Boot - and by the way - no I am not trying to prolong a
fruitless thread, I am just trying to really discuss an important part
of the U-Boot design.

Cheers
  Detlev

-- 
LISP has survived for 21 years because it is an approximate local
optimum in the space of programming languages.
                                           -- John McCarthy (1980)




More information about the U-Boot mailing list