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
Signature · 10 lines
______ Luigi Mantellini
.'______'. R&D - Software
(.' '.) Industrie Dial Face S.p.A.
( :=----=: ) Via Canzo, 4
('.______.') 20068 Peschiera Borromeo (MI), Italy
'.______.' Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
Ind. Dial Face Email: luigi.mantellini at idf-hit.com
www.idf-hit.com GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
B003 175F E979 907E 1650Quoted 6 lines · Luigi 'Comio' Mantellini
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:
Quoted 10 lines
[
0xbe000000->0xbeffffff] Flash#0 CS#0
?[0xbf000000 ->0xbfffffff] Flash#1 CS#1I 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.
Quoted 2 lines
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).
Quoted 5 lines
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.
Quoted 10 lines · Vlad Lungu
Quoted 2 lines · Luigi 'Comio' Mantellini
Hi Guys,
..
Quoted 5 lines
[
0xbe000000->0xbfc00000] JFFS2 root
[0xbfc00000->0xbfe00000] U-BOOT code
[0xbfe00000->0xbfffffff] DATASo you have 16+12Mo then u-boot then 2 Mo left.
Yes. :)
Quoted 5 lines
Quoted 2 lines
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.
Quoted 5 lines
-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.
Quoted 2 lines
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.
Quoted 4 lines
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?
Quoted 8 lines
Quoted 5 lines
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
Quoted 2 lines
Regards,
Vlad
Signature · 10 lines
______ Luigi Mantellini
.'______'. R&D - Software
(.' '.) Industrie Dial Face S.p.A.
( :=----=: ) Via Canzo, 4
('.______.') 20068 Peschiera Borromeo (MI), Italy
'.______.' Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
Ind. Dial Face Email: luigi.mantellini at idf-hit.com
www.idf-hit.com GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
B003 175F E979 907E 1650Quoted 10 lines · Luigi 'Comio' Mantellini
Hi Vlad,
Hi list,see inline comments.
[SNIP]
Quoted 4 lines
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:
Quoted 8 lines
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.
Quoted 11 lines
Quoted 6 lines
-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.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 9 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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.
Quoted 9 lines
Quoted 4 lines
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.
Quoted 10 lines · Vlad Lungu
Quoted 6 lines · Luigi 'Comio' Mantellini
.. 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.
Quoted 5 lines
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...
Quoted 9 lines
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 doREAD_ID.
Ok. This can be a solution.
thanks
luigi
Quoted 2 lines
Vlad
Signature · 10 lines
______ Luigi Mantellini
.'______'. R&D - Software
(.' '.) Industrie Dial Face S.p.A.
( :=----=: ) Via Canzo, 4
('.______.') 20068 Peschiera Borromeo (MI), Italy
'.______.' Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
Ind. Dial Face Email: luigi.mantellini at idf-hit.com
www.idf-hit.com GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
B003 175F E979 907E 1650Quoted 11 lines · Luigi 'Comio' Mantellini
Quoted 4 lines
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.
Quoted 10 lines
Quoted 6 lines
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.
Quoted 11 lines
Quoted 9 lines
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 doREAD_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:
Quoted 10 lines
Quoted 6 lines
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.
Quoted 6 lines
Quoted 4 lines
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.
Quoted 16 lines
Quoted 2 lines
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
Quoted 2 lines
Good luck,
Vlad
Signature · 7 lines
Ing. Luigi Mantellini Industrie Dial Face S.p.A. Via Canzo, 4 20068 Peschiera Borromeo (MI) Tel.: +39 02 5167 2813 Fax: +39 02 5167 2459 E-mail: luigi.mantellini at idf-hit.com
A message that is not in the archive (sent off-list or not yet received): [email protected]
Il giorno mer, 16/04/2008 alle 22.23 +0300, Vlad Lungu ha scritto:
Quoted 5 lines
Luigi 'Comio' Mantellini wrote:
[snip]Quoted 2 lines
I have 2 identical flash chip from spansion.
Can you tell me the part number so I can do a quick check on it?
I'll send you the exact part number tomorrow.
Quoted 8 lines
Quoted 8 lines
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) -----------
Quoted 5 lines
I don't think it works that way in Linux. The devices you're concatenating must be basically the same (both nor or nand, same width, same sector size / OOB area size for NAND, etc ) . That's what I understand after a quick read of the docs.
Yes, you're right. I just proposed a different architecture that is not implemented in U-boot :)
Quoted 8 lines
Quoted 3 lines
MTD Mus is itself a MTD Driver. This infrastructure could be implemented using smart descriptor to keep the need callback.
You could easily do that, but you still need to have similar devices. Anyway, we're talking about an embedded bootloader here, you put too much stuff in it and it gets bigger than the actual application :-)
I don't think that my proposed architecture is more complex than the actual u-boot implementation. Anyway, to implement proposed idea, we need a descriptor that keeps also the needed callbacks (like init, getsize, writebuffer, ...) as well as needed information (address base, bank number, ...). This architecture should permit to integrate and create a single front-end for all mtd devices avoiding to replicate the politics. Every mtd should define just the mechanisms and exports a descriptor.
I think that these considerations are off-topic... but I prefer to share my vision.
Thanks a lot,
luigi
Quoted 2 lines
Vlad
Ing. Luigi Mantellini
Industrie Dial Face S.p.A.
Via Canzo, 4
20068 Peschiera Borromeo (MI)
Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
E-mail: luigi.mantellini at idf-hit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080416/e844efa6/attachment.htm