Both of you (Wolfgang and Brent) Provided me with some new angle to think of...
I believe I will prefare crippling the CFI over Crippling the flash eeprom as I believe it will be easier on our production team... But I will have to play with it some more...
In the past I had my own flag I called CONFIG_FORCE_FLASH SIZE. Suppose I will come with a way to cripple the CFI to work as it should in the latest version, would you like such a feature integrated in the u-boot for all?
Liberty
On Sat, Mar 1, 2008 at 1:55 AM, Wolfgang Denk wd@denx.de wrote:
In message ffc2b1d40802291336s78a050b7i780fe48b9f2671ce@mail.gmail.com you wrote:
I think what you're trying to do is fundamentally broken. Why don't you use the real sizes present on the hardware? Why do you want to lie to yourself and to your users?
I have more then one way to answer this question some are more philosophical then others, But I will choose the bare hardware approach... we "hide" some backup information on the flash. We make sure the user can not access this hiden info by physically lifting the flash legs (there is a programmable part between the flash and the cpu on the bus). So though there may be a 64Mb flash the user really have a 32Mb. It is, in fact, the flash eeprom which lies to the u-boot / linux.
I see.
Any attempt to access these non existing address will lead to bus fault exactly as if the flash was a 32Mb (which in many sense it is). So, again, it is important for me to tell u-boot "go ahaed and use CFI, but dont listen to the eeporm cuz he doesn't know what he is talking about".
I understand what you are trying to do, but I think your conclusion is wrong. The CFI driver was implemented to read the geometry and size information from the flash chips; if the chips cannot provide the correct information (as in your case), they are simply not CFI conformant, and you cannot use the CFI driver.
It may be possible to modify (or cripple) the CFI driver to ignore the information provided by the flash chips, or to overwrite parts of this information (you would have to overwrite at least size and number of sectors [and eventually the start address and first sector offset if you map the flash at a fixed end address]) - but I don't think that makes sense.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Writing a book is like washing an elephant: there's no good place to begin or end, and it's hard to keep track of what you've already covered.