Hi Vlad,
Il giorno mer, 16/04/2008 alle 21.39 +0300, Vlad Lungu ha scritto:
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.
It still feels wrong :-), but I see how this is supposed to work. You're probably using just that 2 Mo piece for data or you're not saving anything on the NOR flash. Highly customized application.
The datas are "stored" on a ramdisk :) The system retrieves the configuration from a remote system during booting.
I cannot store the uImages in separated memory space...
I have some ideas about how you could do it, but it might be too much trouble and not enough gain.
On this point I have a strong constraint: The Kernel image (vmlinux +rootfs) cannot be modified by system.
Ok. This can be a solution.
This should be very easy to test. First, check the data sheet and see if all erase sectors are the same size (64ko or 128ko) or inspect the device geometry (Number of Erase Block Regions,offset 2c in the CFI id string, should be 1). If not, this will probably not work like described and you'll need to hack some structures a bit(provide fake erase block region info, from 2 to 4, if more than 2, you're out of luck, but that's highly unlikely). If they are equal: a) if you're configuring flash_info[] by hand, double the sector number in the first element and don't fill the second b) if you're auto-detecting, don't :-) Dump the info and fill the first element by hand, with twice the number of sectors.
I have 2 identical flash chip from spansion.
Anyway, from my modest point of view, the u-boot flash memory model is too rigid. I would like a "linux" model like this: ----------- | |-> [ MTD Driver ] -> Flash 1 (Nor) ---> flash operation --> | MTD Mux |-> [ MTD Driver ] -> Flash 2 (Nand) | |-> [ MTD Driver ] -> Flash n (XXX) -----------
MTD Mus is itself a MTD Driver. This infrastructure could be implemented using smart descriptor to keep the need callback.
Best regards,
luigi
Good luck, Vlad