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