From: Scott Wood <scottwood@freescale.com>
To: "Mark A. Greer" <mgreer@mvista.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
Date: Sun, 07 Oct 2007 20:31:46 -0500 [thread overview]
Message-ID: <47098882.1010900@freescale.com> (raw)
In-Reply-To: <20071005210320.GE6663@mag.az.mvista.com>
Mark A. Greer wrote:
> Why? Because its only safe to download a zImage to certain "safe" locations.
> Where those "safe" locations are vary by firmware, firmware version, and
> zImage size. This is the issue we're discussing.
In theory, yes -- but in practice the odds of this particular heuristic
choosing an unsuitable address seem slim.
> I've already explained _why_ the link address matters WRT where its downloaded.
Sorry, I was being a bit too pendantic with respect to the distinction
between link and load address.
>>> Also, being able to control the link address (that is, the download
>>> address with some firmwares) is not a u-boot specific issue and we
>>> shouldn't make a u-boot specific solution.
>> How is this a u-boot specific solution?
>
> Because the hoops being jumped through in the patch(es) are to make
> u-boot happy and no other firmware.
No, the "hoops" (which I don't think are sufficiently complicated to
warrant such a name) are to address a generic issue with the bootwrapper
-- it wants to put the kernel at zero. It'd be really nice if, in the
absense of a vmlinux_alloc method, the generic code would do an ordinary
malloc() if there's not enough room at zero.
>> I'd much rather it be automatic than require the user to guess an
>> appropriate value (and be aware in the first place that it needs to be set).
>
> Sure, automatic is nice; conjuring up the magic to make it work in all
> situations isn't.
I think this heuristic would work in most situations, so if we do add a
manual override it should be an override, and not something that
everybody has to put up with.
> Having the link address--and therefore the download address on some
> systems--mysteriously and uncontrollably jump around based on the zImage
> size is asking for trouble.
It's a source of potential issues, but I think "asking for trouble" is
exaggerating somewhat.
-Scott
next prev parent reply other threads:[~2007-10-08 1:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-24 11:36 [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper Valentine Barshak
2007-09-25 2:29 ` David Gibson
2007-09-28 14:23 ` Valentine Barshak
2007-10-03 5:50 ` David Gibson
2007-10-05 1:58 ` Mark A. Greer
2007-10-05 2:25 ` David Gibson
2007-10-05 2:59 ` Mark A. Greer
2007-10-05 3:08 ` Mark A. Greer
2007-10-05 17:30 ` Scott Wood
2007-10-05 21:03 ` Mark A. Greer
2007-10-08 1:31 ` Scott Wood [this message]
2007-10-12 21:53 ` Mark A. Greer
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=47098882.1010900@freescale.com \
--to=scottwood@freescale.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mgreer@mvista.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.