A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
Please don't top-post/full-quote! This is *really* annoying.
In message EA12F909C0431D458B9D18A176BEE4A502469206@dlee02.ent.ti.com you wrote:
Yes indeed I duplicated cfi_flash.c. The changes in my previous patch to CFI were rejected. You indicated see the previous list mail on the subject. Your assertion at that time was to put things into the board specific files was one way to go.
Yes, but not by duplicating thousands of lines of code!
The patch I had at that time was ifdef'ed just for my board in CFI and for the flash part I'm using would seem to show errors. I think those OMAP specific ifdef's may fix errors, but I being its such a highly coupled driver it is very difficult to add in changes with out breaking a lot of boards. How do you suggest real integration into that driver? The 1% changes are minor and isolated now and that's not acceptable what is?
The problem with the previous discussion was that there was no agree- ment wether the board should come up with the flash generally un- locked (which is probably what most users expect and what is assumed in the existing documentation), or if it should be left untouched (which is what some board maintainers want). Detlev ZUndel tried to start a poll of opinions, which - to the best of my knowledge - resulted in no replies at all.
I can see only one way to keep everybody satisfied:
The unlocking feature gets implemented (as part of the common CFI flash driver), with the default that flash automatically gets un- locked when the board comes up (this gives most users the expected standard behaviour).
A new environment variable "flash_unlock" can be defined which, when set to a value that starts with a 'n' (like "setenv flash_unlock no") will turn off the automatic unlock (so board maintainers or users who need to optimize boot times can turn this off, eventually as a default by pre-setting this variable in thier board config file).
It shall be a requirement (1) that the existing commands "lock" and "unlock" work as expected and (2) that the "flinfo" command shows the current lock state correctly, i. e. if the flash comes up locked it *must* be displayed as read-only.
Comments welcome.
[I will accept a clean patch that implements such a solution.]
I certainly can break the patch into parts, but they are all coupled. The chip and board are very new have went though flux and this results in large patches at this time. This is not a PPC821 which shouldn't have a lot of change.
Please separate at least the cfi_flash part.
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: Wednesday, September 28, 2005 6:46 PM To: Woodruff, Richard Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] [PATCH] Update OMAP242x for git head (plus sign).
[Full quote deleted].
Wolfgang Denk