[U-Boot] [PATCH 7/7] sunxi: Add environment settings to make extlinux.conf booting work

[Tom Rini <trini@ti.com>]

On Mon, Aug 04, 2014 at 11:31:14AM -0600, Stephen Warren wrote:
> On 08/01/2014 07:53 PM, Tom Rini wrote:
> >On Fri, Aug 01, 2014 at 03:43:23PM -0600, Stephen Warren wrote:
> >>On 08/01/2014 02:43 PM, Tom Rini wrote:
> >>>On Fri, Aug 01, 2014 at 02:22:40PM -0600, Stephen Warren wrote:
> >>>>On 08/01/2014 02:05 PM, Dennis Gilmore wrote:
> >>>>>On Fri, 01 Aug 2014 12:57:31 -0600
> >>>>>Stephen Warren <swarren@wwwdotorg.org> wrote:
> >>>>>
> >>>>>>On 08/01/2014 01:46 AM, Hans de Goede wrote:
> >>>>>>>Automatic booting using an extlinux.conf file requires various
> >>>>>>>environment variables to be set.
> >>>>>>
> >>>>>>Acked-by: Stephen Warren <swarren@nvidia.com>
> >>>>>>
> >>>>>>I'd personally be tempted to set fdt_high=0xffffffff,
> >>>>>>initrd_high=0xffffffff to stop U-Boot copying the DT/initrd from the
> >>>>>>load location to some other location under 256M, but that's just an
> >>>>>>optimization and entirely optional.
> >>>>>
> >>>>>There has been quite a few times where using 0xffffff has caused
> >>>>>issues.
> >>>>
> >>>>What kind of issues?
> >>>>
> >>>>At least for Tegra, I've carefully chosen the values for the various
> >>>>load addresses so that there won't be issues. (Without that I can
> >>>>easily see the potential for issues.) I've seen far more repeated
> >>>>problems when U-Boot moves the DT/initrd around than than when it
> >>>>didn't (none in that case). Besides, it's completely redundant and
> >>>>unnecessary work if the blobs are already loaded at sane addresses,
> >>>>which they are on Tegra at least.
> >>>
> >>>Just how large of a kernel have you thrown on a Tegra?  32MB might seem
> >>>reasonable at first but it wouldn't be overly surprised if someone can
> >>>shove a BSS into there.  I know I shoved DT into 128MB by default
> >>>because a 32bit ARM kernel isn't functional at that size.
> >>
> >>There's enough space for the following:
> >>
> >>16M decompressed kernel
> >>16M compressed kernel
> >
> >... which is potentially small :)
> 
> Yes, I suppose we should bump the decompressed kernel size to 24M.
> The last time we had this conversation, IIRC there was an agreement
> that since that's the limit of the ARM ISA's branch/jump
> instruction, that's the largest a kernel image could be (and at that
> size, no modules could be loaded). That is, unless intermediate
> trampolines were generated by the linker, which IIRC isn't done.
> 
> FWIW, multi_v7_defconfig is only 11MB uncompressed and 5MB
> compressed, so we're not likely to hit the 16M limit for a while.

Part of why I harp on this is that I've had vendor kernels run past this
16MB limit (some test file had be included in the kernel binary due to
some _other_ problem).  That's why I moved the am33xx stuff (and other
TI bits I could test) to the worst-case must-be-safe limits because you
never know what less-than-ideal thing might get thrown at us later on.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140804/f8ea1fb1/attachment.pgp>