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