All of lore.kernel.org
 help / color / mirror / Atom feed
From: johan.adolfsson@axis.com
To: "Daniel Quinlan" <quinlan@transmeta.com>
Cc: "Johan Adolfsson" <johan.adolfsson@axis.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [RFC/FYI] cramfs 6/6 - boot/root stuff
Date: Tue, 30 Apr 2002 09:39:02 +0200	[thread overview]
Message-ID: <00a601c1f01a$19443180$87b270d5@homeip.net> (raw)
In-Reply-To: <Pine.LNX.4.33.0204291553570.25892-100000@ado-2.axis.se>


"Daniel Quinlan" <quinlan@transmeta.com> wrote in message
news:6yy9f6rw5q.fsf@transmeta.com...
> Johan Adolfsson <johan.adolfsson@axis.com> writes:
>
> > <ugly hack warning>
> > 6. (RFC/FYI) In our tree we have a hack that allows us
> >    to append the cramfs image to the kernel image and use it to boot
from.
> > [...]
> > Any hints of other approaches?
>
> It seems much cleaner to use the padding option to put some boot code
> in the first 512 bytes of the cramfs image which you can use to jump
> to anywhere in the image.
>
> What we did for x86 was to put boot code in the first 512 bytes (the
> "-p" option to mkcramfs), then jump to 512 bytes after the superblock
> start (offset 1024) which was where we put the kernel (put there via the
> "-i" option to mkcramfs, just a normal kernel image padded at the
> beginning by 436 bytes so it would start at offset 1024).
>
> We could have just jumped to offset 588 instead of 1024 and not padded
> the kernel, but we used even numbers for some (aesthetic?) reason that I
> can't recall.
>
> Dan

That wouldn't work that well for us, I think, or at least we
probably couldn't use the same cramfs image for development
(network boot) as for flash boot.

Our normal flash image looks something like this:
64k bootblock
partition table (with code that jumps over it)
decompressor
compressed kernel
cramfs image
padding
JFFS partition

the compressed kernel is decompressed to RAM and started.
I agree that having the compressed kernel as part of the
cramfs image would be nice, but is the image exposed in the
filesystem as well?
It doesn't look like it when I look at the code.
That could be a nice feature as well.

During development, we download an image to RAM directly without
flashing it which takes two seconds or so instead of waiting for the
flash chips to be erased. That image contains the kernel (not compressed)
with an appended cramfs image.
I don't think we can waste that additional amount of RAM by having
the kernel both uncompressed and then compressed in the cramfs image,
at least not for hardware with only 8MB RAM.

I did some fiddling with the MTD RAM yesterday and think I got it
to work after some editing, patches will be submitted to the mtd list.

/Johan



      parent reply	other threads:[~2002-04-30  7:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-29 14:42 [RFC/FYI] cramfs 6/6 - boot/root stuff Johan Adolfsson
2002-04-29 22:13 ` Daniel Quinlan
2002-04-30  7:39 ` johan.adolfsson [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='00a601c1f01a$19443180$87b270d5@homeip.net' \
    --to=johan.adolfsson@axis.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quinlan@transmeta.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.