From: "Robert P. J. Day" <rpjday@mindspring.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Wolfgang Denk <wd@denx.de>,
Embedded Linux PPC list <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: loading the kernel and root FS separately from flash?
Date: Mon, 28 Jun 2004 06:19:36 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.60.0406280615400.3259@localhost.localdomain> (raw)
In-Reply-To: <1088415754.6992.1.camel@hades.cambridge.redhat.com>
On Mon, 28 Jun 2004, David Woodhouse wrote:
> On Mon, 2004-06-28 at 09:09 +0200, Wolfgang Denk wrote:
>>> is this possible? anyone done it this way, and can tell me what
>>> pitfalls i have to watch for? thanks.
>>
>> 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). Instead, we usually split
>> the stuff in a read-only partition (for example cramfs), a volatile
>> part (tmpfs), and a persistent storage partition (JFFS2).
>
> I think it should be OK when it's 4MiB in size. Mount time was far more
> of a problem in JFFS2 many years ago when people were using the 2.4
> kernel. It's a lot faster in 2.6.
>
> There's people looking at making it even faster now, too.
we're still using the 2.4 kernel here, but i don't think boot/mount
time is an issue. i mean, someone's just going to turn the unit on,
wait to get a "READY" prompt, and go to work. if it takes a bit
longer, tough. :-)
it was more the response time from flash as opposed to RAM that was an
issue for me. that's why i was asking about having the root FS loaded
from flash into RAM at boot time. we'd probably be happy about
sacrificing boot time response (copying all of the root FS into RAM)
for better run time performance, although i don't know the differences
in performance at the moment.
but i like the fact that it's snappier under 2.6.
rday
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2004-06-28 10:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-27 22:46 loading the kernel and root FS separately from flash? Robert P. J. Day
2004-06-28 3:58 ` Eugene Surovegin
2004-06-28 10:00 ` Robert P. J. Day
2004-06-28 7:09 ` Wolfgang Denk
2004-06-28 9:42 ` David Woodhouse
2004-06-28 10:19 ` Robert P. J. Day [this message]
2004-06-28 10:48 ` Wolfgang Denk
2004-06-28 10:52 ` Robert P. J. Day
2004-06-28 10:23 ` Robert P. J. Day
2004-06-28 10:36 ` Wolfgang Denk
2004-06-28 10:40 ` David Woodhouse
2004-06-28 10:13 ` Robert P. J. Day
2004-06-28 10:41 ` Wolfgang Denk
2004-06-28 10:50 ` Robert P. J. Day
2004-06-29 9:31 ` David Woodhouse
2004-06-29 12:09 ` Robert P. J. Day
-- strict thread matches above, loose matches on Subject: below --
2004-06-28 11:33 Gerhard TAEUBL
[not found] <s0e01d9a.092@mail.frequentis.com>
2004-06-28 12:11 ` Robert P. J. Day
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=Pine.LNX.4.60.0406280615400.3259@localhost.localdomain \
--to=rpjday@mindspring.com \
--cc=dwmw2@infradead.org \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=wd@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).