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

[Stephen Warren]

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 at 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 at 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.

>> 1M DTB
>>
>> The kernel I typically boot is ~4.MB zImage, and ~9MB Image (which
>> doesn't include BSS).
>>
>> Note that if the decompressed/compressed kernel overlap, the kernel
>> decompresser takes care of relocating the compressed kernel before
>> doing the decompression, and IIRC is supposed to take care not to
>> clobber the DTB (or initrd?) when doing so.
>
> The decompressor is happy to clobber over other things I would swear
> which is how people end up in the "oops, my DT was eaten" case when
> things are placed too close and _not_ relocated prior to booting.
>
>> Fedora's rawhide zImage is a bit larger at ~6MB. That works fine too.
>
> Right but what's the worst case you can come up with?  There's folks out
> there attempting to feed the same kernel into their testboard farm of
> relatively wild differnet HW but all works on multi_v7_defconfig.

Hmm. Some experimentation shows that if the DTB is loaded where the 
kernel will be decompressed to, then the DTB does indeed get clobbered.

Still, the Tegra default environment already places the DTB 32MB after 
the decompressed kernel location, so that won't be an issue (unless 
there's a 24MB kernel with 8MB BSS, which is very unlikely). If we fix 
the size allocated to the decompressed kernel to be the full 24MB, the 
issue would then only occur with a 24MB uncompressed kernel with 16MB 
BSS. That's even more unlikely. For tegra_defconfig or 
multi_v7_defconfig, BSS is currently 3/8MB and 1/4MB respectively.