loading the kernel and root FS separately from flash?

[Robert P. J. Day]

(sorry, i realize that this isn't directly related to PPC issues.)

as a first followup question, now that i've just created a 4M
partition on an 8M flash chip, and formatted it as JFFS2, if i put a
copy of the root FS on that filesystem, i can of course boot and use
that as my root filesystem.  but, at the moment, since i'm booting
with what is essentially a zImage.initrd, the kernel is first loaded,
and then the uncompressed root filesystem is copied into RAM of
course.

i suspect that leaving my root filesystem in flash would cause
noticeable performance problems (even if i managed to structure it so
that it could be read-only).  how hard would it be to automatically
have that root FS copied from JFFS2 to RAM and mounted from there?
can that be done as a kernel option i haven't seen?  or do i have to
do that manually, involving something like "pivot_root"?  or is it
worth the trouble?

On Mon, 28 Jun 2004, Wolfgang Denk wrote:

> In message <Pine.LNX.4.60.0406271836300.10210 at localhost.localdomain> you wrote:
>>
>>    with this configuration, it's obviously not possible to update files
>> or directories in the bootable image individually -- it's just one big
>> zImage.initrd image.
>
> What makes you think that this is not  possible?  If  there  is  (for
> example)  a  writable JFFS2 partition available, you can use this for
> an overlay filesystem to store the updates.
>
> See for example the "mini_fo" overlay filesystem on  our  FTP  server
> and the paper about it:
> http://www.denx.de/PDF/Diplomarbeit-MK-1.0-net.pdf

ah, now this looks interesting.  from a quick glance, is this just a
theoretical concept, or has it been implemented?  we have *some* JFFS2
space available, but not a guaranteed amount.  if this requires a
completely separate JFFS2 partition, we might not be able to handle
that.

>>    but is it feasible to redefine the layout of that flash chip and
>> take, say, 4M of it and create a JFFS2 filesystem, then put the root
>> filesystem in there uncompressed?  (assuming, of course, that the
>
> Standard JFFS2 code will always compress.

sorry, i'm not sure what you're saying here.  are you saying that i
can create a compressed JFFS2 image of my root filesystem on my build
host, just as i do when i create my zImage.initrd?  or just compress
the individual files in the filesystem?  and have this filesystem
automatically loaded into, and mounted from, RAM?  can you clarify
this?

> This is a pretty standard setup. Although I don't really recommend to
> use JFFS2 for root filesystem (for example, because with a  big  root
> filesystem  the boot time may deteriorate).

that was one of my concerns -- not just the boot time but the run
time, even if i could structure it as read-only.

> Instead, we usually split the stuff in a read-only partition (for
> example cramfs), a volatile part (tmpfs), and a persistent storage
> partition (JFFS2).

that's awfully close to what we're doing now.  we've got the tmpfs, we
have a completely separate flash for persistent apps and data, it's
just the root filesystem that i would *dearly* love to be able to
patch on the fly on a running system.  i'll look a lot more closely
into the above.  thanks.

rday

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/