Hi Vlad and list,
see inline comments.
On mer, 2008-04-16 at 16:05 +0300, Vlad Lungu wrote:
Luigi 'Comio' Mantellini wrote:
.. cut...
The answer is pretty simple: the flash layout is a project constraint :D. I know that this approach is very slow, but the target application is a device that should be rebooted about once in a year.
Well, it all depends if you really mean loopback or if it is ramdisk. Loopback feels totally wrong unless the rootfs is read-only.
The rootfs will be Read-only. Any write access will be redirected to a ramdisk. Only during the "upgrading" activity the JFFS2 will be write from an custom user application, while during the normal activity both JFFS2 and loopback-mounted Root filesystem will be Read-only.
Really. If it is ramdisk, I guess you could store uImages directly in the NOR flash (one at the beginning, one at the end so you know you can easily replace any of them, or if you know that they are <9Mo, 3 of them equally spaced).
I cannot store the uImages in separated memory space...
Anyway, back to your original question: if the flash devices are identical and the erase sectors have the same size, you could probably fill flash_info[] yourself instead of auto-detecting and pretend you have a single flash twice the size (i.e. 32Mo). After all, this is NOR flash so you're not actually using sector numbers like with NAND parts. And the addresses are consecutive, so for all intents and purposes, it looks like a big flash until you do READ_ID.
Ok. This can be a solution.
thanks
luigi
Vlad