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 <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > 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. > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ U-Boot-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/u-boot-users
