[U-Boot-Users] MTD Concat support

[Vlad Lungu]

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