From: Vlad Lungu <vlad@comsys.ro>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] MTD Concat support
Date: Wed, 16 Apr 2008 21:39:53 +0300 [thread overview]
Message-ID: <480647F9.4080305@comsys.ro> (raw)
In-Reply-To: <1208354132.26135.61.camel@localhost>
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
next prev parent reply other threads:[~2008-04-16 18:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-16 10:44 [U-Boot-Users] MTD Concat support Luigi 'Comio' Mantellini
2008-04-16 11:47 ` Vlad Lungu
2008-04-16 12:26 ` Luigi 'Comio' Mantellini
2008-04-16 13:05 ` Vlad Lungu
2008-04-16 13:55 ` Luigi 'Comio' Mantellini
2008-04-16 18:39 ` Vlad Lungu [this message]
2008-04-16 19:11 ` Luigi 'Comio' Mantellini
[not found] ` <48065219.6030003@comsys.ro>
2008-04-16 21:06 ` Luigi 'Comio' Mantellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=480647F9.4080305@comsys.ro \
--to=vlad@comsys.ro \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.