Luigi 'Comio' Mantellini wrote:
Hi Vlad, Hi list,
see inline comments.
[SNIP]
That's a rather big JFFS filesystem. Do you plan booting from it? Isn't it rather slow? It would take a few seconds (5-10) to scan the FS on this under U-Boot. I would recommend two strategies here:
I know that the JFFS2 is rather slow, but I have this constraint on my application. The kernel images are provided as a big all-in-one file that contains the kernel and the rootfs (which will mounted via a loopback device). Unfortunately I cannot change this logic because a lot of user-space software (made by external providers) assumes a big images repository to store the monolithic images.
At 8-10Mo, that's 2 , maybe 3 images. Definitely only 2 if you want any kind of performance on this thing (full JFFS filesystems tend to be rather slow on write). As for loopback ... do you mean ramdisk, by any chance? If not, is that some custom image format? Or you store the fs image uncompressed in the uImage and play games with offset and length? In that case, you're killing performance again.
-put the uImage directly in the NOR flash. Maybe in those 2 Mo at the end or somewhere else. Update it from Linux or if you screw up, from the network. -create a smaller partition (like 4Mo) and keep two kernels there, main and spare. Mount it under /boot in Linux.
I cannot follow these solutions because I need to keep monolithic images (large about 8-10 MB) without explode them.
I was thinking in terms of smallish kernels + root on JFFS. This is not the case, it seems.
Boot from there. Use the rest of the available space as root with the MTD concat driver but don't touch it from U-Boot.
The JFFS2 partition will not contain the ready-for-use rootfs but monolithic images that will be mounted using the loopback devices. This is a constraint of my application :S and I cannot change it.
In this case, using JFFS is definitely overkill.
Will boot much faster than from a 28Mo partition, you can use *summary* information on root (not supported in U-Boot) for faster mount in Linux, more versatile than uImage in NOR (you can have 1 or more spares depending on kernel sizes and partition size).
Can you explain this point?
This was valid in the context of "rootfs on JFFS", so disregard the observations.
How I can say to U-boot to consider the two flashes as a single space of memory (in order to place a big JFFS2 filesystem)? In Linux I can achieve this using the MTD Concat driver but I don't understand How I can do in U-boot.
What you are asking could be already possible, or require just a few modifications, but you have to ask yourself: do I really HAVE to do this?
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. 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).
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.
Vlad