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
