Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Jun Sun <jsun@mvista.com>
To: Dan Malek <dan@embeddededge.com>
Cc: Tibor Polgar <tpolgar@freehandsystems.com>,
	Mark Salter <msalter@redhat.com>,
	krishnakumar@naturesoft.net, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: Ramdisk image on flash.
Date: Thu, 20 Feb 2003 12:44:56 -0800	[thread overview]
Message-ID: <20030220124456.G7466@mvista.com> (raw)
In-Reply-To: <3E553C03.10207@embeddededge.com>; from dan@embeddededge.com on Thu, Feb 20, 2003 at 03:35:15PM -0500

On Thu, Feb 20, 2003 at 03:35:15PM -0500, Dan Malek wrote:
> Tibor Polgar wrote:
> 
> > The original poster wanted a setup where the initrd was NOT part of the
> > kernel, which begs the question of how/where it would be put into flash so
> > something could load/uncompress it. 
> 
> I regularly do this with compressed kernels (zImage) on PowerPC, ARM, and
> Alchemy MIPS processors.  I attach the compressed ramdisk to the zImage,
> usually with "cat" and some shell scripts.  The zImage uncompressor code
> will relocate the ramdisk (and potentially ask for additional kernel
> command line parameters) and will tell the kernel where the ramdisk is
> located.  I don't have to recompile the kernel to do this, and best of
> all it doesn't require any special boot rom knowledge of the image.  It
> works with all boot roms that can load a binary image into a memory location
> (not everyone uses RedBoot) :-)  Another advantage is exactly the same
> image that you repeatedly test by loading over tftp or with a debugger
> can be written into flash memory without modification.  It removes the
> need to actually have to write to flash to test the image that will be
> eventually written to flash.  You just jump to the start of the image to
> uncompress/relocate/initialize/jump to kernel regardless of where it
> is located.
>

Looks like you have the solution that I called for. :-)
 
> 
> There are a couple of things keeping me from making a patch for the MIPS
> kernel.  This method is in conflict with the "compiled in" ramdisk method,
> and reserving the "bootmem" pages to ensure the kernel doesn't allocate the
> compressed ramdisk pages before they are freed doesn't work well compared
> to other architectures.  I'm still running on luck with this latter problem,
> but I think I can fix it.  I don't know yet what to do about the conflicts
> and assumptions made about the compiled-in ramdisk.
>

The compiled-in one uses a configure option.  Perhaps you can rely on that
to differentiate?  Once the new method get stable, I am in favor to 
covert all embedded ramdisk to the new one.

Jun

  reply	other threads:[~2003-02-20 20:45 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-20  6:05 Ramdisk image on flash Krishnakumar. R
2003-02-20 18:27 ` Pete Popov
2003-02-20 19:30   ` Tibor Polgar
2003-02-20 19:41     ` Mark Salter
2003-02-20 20:01       ` Tibor Polgar
2003-02-20 20:16         ` Mark Salter
2003-02-20 20:35         ` Dan Malek
2003-02-20 20:44           ` Jun Sun [this message]
2003-02-20 20:57             ` Pete Popov
2003-02-20 21:24               ` Dan Malek
2003-02-20 20:37         ` Jun Sun
2003-02-20 21:08           ` Guido Guenther
2003-02-20 21:12         ` Alan Cox
2003-02-20 19:41     ` Pete Popov
2003-02-20 19:42     ` Brian Murphy
2003-02-20 20:59   ` Guido Guenther
2003-02-20 21:27     ` Dan Malek
2003-02-21  2:24 ` Atsushi Nemoto
2003-02-21 20:25   ` fixup_bigphys_addr and DBAu1500 dev board Jeff Baitis
2003-02-21 20:40     ` Dan Malek
2003-02-21 22:10       ` Pete Popov
2003-02-22  3:50       ` Jeff Baitis
2003-02-23  9:19         ` Geert Uytterhoeven
2003-02-24 17:46         ` Pete Popov
2003-02-25 21:54           ` Jeff Baitis
2003-02-25 22:05             ` Pete Popov

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=20030220124456.G7466@mvista.com \
    --to=jsun@mvista.com \
    --cc=dan@embeddededge.com \
    --cc=krishnakumar@naturesoft.net \
    --cc=linux-mips@linux-mips.org \
    --cc=msalter@redhat.com \
    --cc=tpolgar@freehandsystems.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox