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