[U-Boot-Users] MTD Concat support

[U-Boot-Users] MTD Concat support

[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:

[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 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 1650

[U-Boot-Users] MTD Concat support

[Vlad Lungu]

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

[U-Boot-Users] MTD Concat support

[Luigi 'Comio' Mantellini]

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 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 1650

[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

[U-Boot-Users] MTD Concat support

[Luigi 'Comio' Mantellini]

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 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 1650

[U-Boot-Users] MTD Concat support

[Vlad Lungu]

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

[U-Boot-Users] MTD Concat support

[Luigi 'Comio' Mantellini]

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

-- 
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
  

[U-Boot-Users] MTD Concat support

[Luigi 'Comio' Mantellini]

Il giorno mer, 16/04/2008 alle 22.23 +0300, Vlad Lungu ha scritto:

> Luigi 'Comio' Mantellini wrote:
> [snip]
> > 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.


> > 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)
> >                          -----------
> >   
> 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 :)


> > 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


> 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