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.