linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: "Mark A. Greer" <mgreer@mvista.com>,
	Scott Wood <scottwood@freescale.com>,
	linuxppc-dev@ozlabs.org, paulus@samba.org
Subject: Re: [PATCH 17/19] bootwrapper: compatibility layer for old U-Boots (a.k.a. cuImage, cuboot)
Date: Thu, 15 Mar 2007 13:05:38 +1100	[thread overview]
Message-ID: <20070315020538.GC14061@localhost.localdomain> (raw)
In-Reply-To: <20070315020234.GB14061@localhost.localdomain>

On Thu, Mar 15, 2007 at 01:02:34PM +1100, David Gibson wrote:
> On Wed, Mar 14, 2007 at 06:59:04PM -0700, Mark A. Greer wrote:
> > On Thu, Mar 15, 2007 at 11:04:45AM +1100, David Gibson wrote:
> > > On Wed, Mar 14, 2007 at 04:23:39PM -0700, Mark A. Greer wrote:
> > > > On Wed, Mar 14, 2007 at 04:48:49PM -0500, Scott Wood wrote:
> > > > > Mark A. Greer wrote:
> > > > > >Are you sure that '_end' (which is the end of the zImage/cuImage)
> > > > > >is safe to use?  If the kernel is large enough (e.g., INITRAMFS)
> > > > > >it will overwrite your dtb when its decompressed and relocated to 0.
> > > > > >You need to grok the elfheader to figure out where the kernel will end
> > > > > >and take the max of that and _end.
> > > > > 
> > > > > Wouldn't it overwrite the bootwrapper itself before overwriting the heap?
> > > > 
> > > > Sure but that doesn't matter--the kernel is running so the bootwrapper's
> > > > life is over but the dtb's life isn't.
> > > 
> > > The bootloader now expands the kernel directly at 0, rather than
> > > allocating space for it, except on platforms that can't (OF).
> > 
> > Well, its not at 0 if you have a platform_ops.vmlinux_alloc()
> > defined which could be anyone.  But I get your point.
> 
> Well, yes, but cuboot doesn't.  The platforms always going to have to
> define a malloc() and vmlinux_alloc() that don't conflict with each
> other.
> 
> > > So we
> > > *would* clobber the bootloader during the bootloader's life if the
> > > kernel was too large.  There's a check for a too-large kernel as we
> > > decompress it.
> > 
> > This seems like a problem to me.  Premably, INITRAMFS will be used
> > more & more often so this check is going to fail more & more often.
> > We'll end up havng to keep moving the addr it loads at further & further
> > back or define platform_ops.vmlinux_alloc() and have the issue I
> > mentioned.
> 
> Err... won't the initramfs image go in the same place as the initrd
> image, not as part of the vmlinux.

Although, speaking of that.  Long term, I think it would be a good
idea for the wrapper script to base the zImage's link address on the
size of the vmlinux.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

  reply	other threads:[~2007-03-15  2:05 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-12 20:42 [PATCH 17/19] bootwrapper: compatibility layer for old U-Boots (a.k.a. cuImage, cuboot) Scott Wood
2007-03-12 21:07 ` Kumar Gala
2007-03-13 18:16   ` Scott Wood
2007-03-13 18:50     ` Kumar Gala
2007-03-13 19:01       ` Scott Wood
2007-03-13 19:13         ` Kumar Gala
2007-03-13 19:25           ` Scott Wood
2007-03-12 21:12 ` Kumar Gala
2007-03-13 15:28 ` Scott Wood
2007-03-14  4:25 ` Paul Mackerras
2007-03-14 15:59   ` Scott Wood
2007-03-14 16:08     ` Kumar Gala
2007-03-14 16:45       ` Kim Phillips
2007-03-14 23:36     ` David Gibson
2007-03-15 15:17       ` Scott Wood
2007-03-14  6:35 ` David Gibson
2007-03-14 16:59   ` Scott Wood
2007-03-14 23:56     ` David Gibson
2007-03-15 16:40       ` Scott Wood
2007-03-16  0:09         ` David Gibson
2007-03-14 21:48 ` Mark A. Greer
2007-03-14 21:48   ` Scott Wood
2007-03-14 23:23     ` Mark A. Greer
2007-03-15  0:04       ` David Gibson
2007-03-15  1:59         ` Mark A. Greer
2007-03-15  2:02           ` David Gibson
2007-03-15  2:05             ` David Gibson [this message]
2007-03-15  2:15               ` Mark A. Greer
2007-03-15  2:12             ` Mark A. Greer
2007-03-29 23:12             ` Milton Miller
2007-03-15  0:01   ` David Gibson

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=20070315020538.GC14061@localhost.localdomain \
    --to=david@gibson.dropbear.id.au \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mgreer@mvista.com \
    --cc=paulus@samba.org \
    --cc=scottwood@freescale.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;
as well as URLs for NNTP newsgroup(s).