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

[Tolunay Orkun <listmember@orkun.us>]

Hi Detlev,

I am almost banished for causing this discussion and I will probably be 
subjected to "tar and feathers" after this :)

Detlev Zundel wrote:
> Hello all,
> 
> sorry for jumping in so late in this discussion but I just want to
> make my opinion heard.
> 
> For what its worth, I consider "unlocking everything besides u-boot
> relevant code (or add something to the opposite in your board code)"
> as policy.  I think U-Boot should provide the mechanisms, i.e. commands
> to protect and unprotect sectors and by correctly indicating protected
> sectors in the fli display.

Yes, I consider this as a "policy" as well.

> I think Wolfgang votes against this as he expects u-boot to provide
> him with a common view over many boards - thus seeing the hardware
> protection by default rather as a design decision to be abstracted by
> u-boot.

But, he is making an assumption on the usage of portions of flash which 
is not defined by U-Boot.

A bootloader is only one part of the total software solution. There is 
typically an application loaded following the U-Boot portion that 
defines the usage of portion of hardware that might be shared with 
U-Boot. Even if you might have common hardware you could end up uncommon 
usage since it is more appropriate to the application. This is typically 
the case for off-the-shelf boards that gets embedded in many different 
applications.

> Therefore I guess one question that should drive the design of u-boot
> code is
> 
> Q: Is hardware protection in flash chips a deliberate measure by the
>    board designer not to be abstracted by the bootloader?
 > If the answer is "no" then the current design is presenting this
 >
 > u-boot abstraction on every board.
 >
 > If on the other hand the answer is "yes" then I think u-boot should
 > not make all flash writable by default.

The answer is "No" in some cases and in others it is a "Yes". However, 
once the choice of chip is made, there are implications of the choice.

When the answer is "No", convenience, availability, cost are probably 
factors that resulted in the current hardware design. In this case, the 
designer generally does not have a preference. Other factors have had 
higher importance with that choice.

When the answer is "Yes", the designer really desires to use that 
feature as presented by the hardware.

So, should U-Boot be making the abstraction suitable for this lowest 
common denomiator, denying the capabilities of more featured chips? I 
think U-Boot should not match the common denominator but rather reflect 
the capabilities of actual hardware and provide necessary and sufficient 
tools to deal with it. I would like to see the common view in the tools 
presented but any further abstraction is abstraction gone too far, too 
rigid.

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.

Best regards,
Tolunay Orkun