All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@kernel.crashing.org>
To: Magnus Damm <damm@opensource.se>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: bi_record and initrd
Date: Tue, 19 Nov 2002 11:11:07 -0700	[thread overview]
Message-ID: <20021119181107.GD779@opus.bloom.county> (raw)
In-Reply-To: <3DD4E271.16FA374A@opensource.se>


On Fri, Nov 15, 2002 at 01:02:57PM +0100, Magnus Damm wrote:

> > Can you give more information about where everything is loaded up at?  I
> > thought this was a non-issue, but it's been a while since I tested
> > initrds.
>
> Sure.
[snip]
> this mail says something about typos or misuse of _ALIGN().
> http://www.geocrawler.com/archives/3/8358/2002/9/0/9715261/

I _think_ this is intentional, ie make sure we have bigger than needed
alignments, possibly to try and avoid what we've hit here.

> If _ALIGN() now is used correctly, then the align definition
> maybe chould be changed from
> #define _ALIGN(addr,size)        (((addr)+size-1)&(~(size-1)))
> to
> #define _ALIGN(addr,size)        (((addr)+(size)-1)&(~((size)-1)))
> to make sure that size is treated correctly. Or maybe it's a feature. =)

Fixing that now, thanks.

> Second example:
[snip]
> I have not been able to output the value of zimage_size for this case, but I'm
> sure that my initrd gets overwritten with the bi_record at 0x00200000.

Yeah, I'm sure too.  Here's an untested patch vs current
linuxppc_2_4_devel, which will relocate the initrd if needed.  The
current bi_rec code in the kernel shouldn't care if the initrd is moved
(This was broken in the past and then pointed out / fixed later, so I'm
rather confident of this part :)) so it should be OK.

For 2.5, I'm pondering going back and re-reading all of the discussions
and maybe even starting on it, with an arbitrary location for the
bi_recs which would let this case be much simpiler.

> Another thing - why is the second argument (dstlen) to gunzip() always 4 megabytes?
> Maybe it could be set to the address that the image is loaded at / relocated to?
> (0x180000 above) That way the gunzip function wouldn't overwrite the running code,
> if I understand the dstlen argument correctly that is.

I'm not sure about this part.  Tested patches are welcome of course. :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

  parent reply	other threads:[~2002-11-19 18:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-14 15:54 bi_record and initrd Magnus Damm
2002-11-14 17:48 ` Tom Rini
2002-11-15 12:02   ` Magnus Damm
2002-11-15 17:08     ` Cort Dougan
2002-11-18  8:19       ` Magnus Damm
2002-11-18 17:13         ` Tom Rini
2002-11-19  4:29         ` Murray Jensen
2002-11-18 14:19       ` Tom Rini
2002-11-19 18:11     ` Tom Rini [this message]
2002-11-19 18:19       ` Tom Rini
  -- strict thread matches above, loose matches on Subject: below --
2002-11-27 21:00 Richard Laing

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=20021119181107.GD779@opus.bloom.county \
    --to=trini@kernel.crashing.org \
    --cc=damm@opensource.se \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    /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.