From: Oliver Korpilla <okorpil@fh-landshut.de>
To: Magnus Damm <damm@opensource.se>
Cc: mgroeger@sysgo.com, linuxppc-embedded@lists.linuxppc.org
Subject: Different solution
Date: Wed, 28 Apr 2004 09:28:25 +0200 [thread overview]
Message-ID: <408F5D19.7010002@fh-landshut.de> (raw)
In-Reply-To: <20040427153908.4f1eeb8a.damm@opensource.se>
Magnus Damm wrote:
>
> I don't know what magic patches that are applied to the mvl-3.1 kernel
> that a customer of mine use, but we use one kernel with initrd (ext2fs)
> and nfs root + ip pnp support. Then we select at boot-time how we want
> to boot the system:
>
> Development: "noinitrd ip=on nfsroot=192.168.1.1:/home/nfs/foobar"
> Standalone: "ip=off"
>
> We boot a "Gzipped Multi-File Image" from u-boot, but I guess that booting
> a standard zImage from anywhere would do too.
>
A quicker solution was to use my flash as a JFFS2 root filesystem (it
was actually quite complicated, because write support in the kernel
(MTD) is broken for the onboard flash chip - well, read it on the
linux-mtd ;) ). I now mount this readonly, and I have a filesystem
without needing to reserve RAM for it - where the initrd resides. So
this is actually a better solution, that utilizes my ressources better. :)
I would like to still found a solution incorporating an initrd, but in
this case only for completeness' sake.
Anybody ideas about how of if to set the following parameters:
root, rootfstype, keepinitrd
and any others needed to use the initrd?
Residual-Data Located at: $01F5511C
loaded at: 00005400 001655BC
relocated to: 00800000 009601BC
zimage at: 008058B0 008C16FA
initrd at: 008C2000 0095D000
avail ram: 00400000 00800000
I'm a bit unsure whether these are good values, or if the place the
initrd is relocated to at loading is actually problematic - e.g.
problematic with regards to HIGHMEM, or end of memory. I have 32MB of
physical mem.
Hope I didn't demotivate anyone to find a solution, though! ;)
With kind regards,
Oliver Korpilla
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
prev parent reply other threads:[~2004-04-28 7:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-21 13:16 Initrd and PPCbug, can it work? okorpil
2004-04-26 22:09 ` Tom Rini
2004-04-27 6:39 ` Oliver Korpilla
2004-04-27 7:18 ` Marius Groeger
2004-04-27 8:50 ` Oliver Korpilla
2004-04-27 9:22 ` Marius Groeger
2004-04-27 9:42 ` Oliver Korpilla
2004-04-27 10:48 ` Magnus Damm
2004-04-27 12:42 ` Oliver Korpilla
2004-04-27 11:13 ` Marius Groeger
2004-04-27 12:45 ` Oliver Korpilla
2004-04-27 13:39 ` Magnus Damm
2004-04-27 16:17 ` Different solution Oliver Korpilla
2004-04-28 7:28 ` Oliver Korpilla [this message]
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=408F5D19.7010002@fh-landshut.de \
--to=okorpil@fh-landshut.de \
--cc=damm@opensource.se \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=mgroeger@sysgo.com \
/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.