[U-Boot-Users] MTD Concat support
Hi Guys,
I'm a question regarding the MTD Concat support in U-BOOT. My system has 2 Flash (x16MB) driven by 2 different Chipselects. The memory layout is the following:
[0xbe000000 -> 0xbeffffff ] Flash#0 CS#0 [0xbf000000 -> 0xbfffffff ] Flash#1 CS#1
I would link to create a JFFS2 partition across the two flash banks with size about 28M. In other hands I should meet the following partition layout:
[0xbe000000 -> 0xbfc00000 ] JFFS2 root [0xbfc00000 -> 0xbfe00000 ] U-BOOT code [0xbfe00000 -> 0xbfffffff ] DATA
Into the JFFS2 filesystem there are the Kernel images and a lot of spare datas.
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.
Thanks a lot for any comments.
ciao
luigi
Luigi 'Comio' Mantellini wrote:
Hi Guys,
I'm a question regarding the MTD Concat support in U-BOOT. My system has 2 Flash (x16MB) driven by 2 different Chipselects. The memory layout is the following:
[0xbe000000 -> 0xbeffffff ] Flash#0 CS#0 [0xbf000000 -> 0xbfffffff ] Flash#1 CS#1
I would link to create a JFFS2 partition across the two flash banks with size about 28M. In other hands I should meet the following partition layout:
[0xbe000000 -> 0xbfc00000 ] JFFS2 root [0xbfc00000 -> 0xbfe00000 ] U-BOOT code [0xbfe00000 -> 0xbfffffff ] DATA
So you have 16+12Mo then u-boot then 2 Mo left.
Into the JFFS2 filesystem there are the Kernel images and a lot of spare datas.
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: -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. 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. 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).
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?
Regards, Vlad
Hi Vlad, Hi list,
see inline comments.
On mer, 2008-04-16 at 14:47 +0300, Vlad Lungu wrote:
Luigi 'Comio' Mantellini wrote:
Hi Guys,
..
[0xbe000000 -> 0xbfc00000 ] JFFS2 root [0xbfc00000 -> 0xbfe00000 ] U-BOOT code [0xbfe00000 -> 0xbfffffff ] DATA
So you have 16+12Mo then u-boot then 2 Mo left.
Yes. :)
Into the JFFS2 filesystem there are the Kernel images and a lot of spare datas.
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.
-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.
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.
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?
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.
Thanks a lot for your observations.
ciao
luigi
Regards, Vlad
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
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
Luigi 'Comio' Mantellini wrote:
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.
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.
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...
I have some ideas about how you could do it, but it might be too much trouble and not enough gain.
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.
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.
Good luck, Vlad
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
participants (2)
-
Luigi 'Comio' Mantellini -
Vlad Lungu