[5/5] ARM: Tegra: Use calc env var feature on all boards

From: Tom Warren <twarren at nvidia.com>

Large kernels (>32MB) can fail to boot because they overwrite the FDT
address, corrupting the DTB. Stephen Warren had created a fix to
dynamically adjust the fdt/ramdisk/pxefile/kernel addr vars at boot time
for T186, which allows a large kernel to load and boot.

This is based on his commit, but applied to the tegraXXX-common.h
headers so it's used on all T186 and T210 Jetson boards. Note that I've
put the kernel 'size' param at 0x03000000, or 48MB, to leave room for
kernel growth. Current L4T kernels are running at about 32MB.

Signed-off-by: Tom Warren <twarren at nvidia.com>
---
 include/configs/p2771-0000.h      | 23 ++---------------------
 include/configs/tegra186-common.h | 22 ++++++++++++++++++++--
 include/configs/tegra210-common.h | 23 ++++++++++++++++++++---
 3 files changed, 42 insertions(+), 26 deletions(-)

On 3/16/20 1:40 PM, twarren at nvidia.com wrote:
> From: Tom Warren <twarren at nvidia.com>
> 
> Large kernels (>32MB) can fail to boot because they overwrite the FDT
> address, corrupting the DTB. Stephen Warren had created a fix to
> dynamically adjust the fdt/ramdisk/pxefile/kernel addr vars at boot time
> for T186, which allows a large kernel to load and boot.

That was actually done to support holes in the RAM map; it's not
actually required in order to support large kernels at all. We could
just as easily directly modify the existing hard-coded load addresses.

> This is based on his commit, but applied to the tegraXXX-common.h
> headers so it's used on all T186 and T210 Jetson boards. Note that I've
> put the kernel 'size' param at 0x03000000, or 48MB, to leave room for
> kernel growth. Current L4T kernels are running at about 32MB.

I had completely forgotten that we had the calculated env vars feature
upstream already!

I thought we went with 96 or 128MB space for the kernel downstream, to
make sure there'd "never" any future problem as the kernel grows?

But this patch seems OK for now I guess.

-----Original Message-----
From: Stephen Warren <swarren at wwwdotorg.org> 
Sent: Tuesday, March 17, 2020 10:38 AM
To: Tom Warren <TWarren at nvidia.com>
Cc: u-boot at lists.denx.de
Subject: Re: [PATCH 5/5] ARM: Tegra: Use calc env var feature on all boards

External email: Use caution opening links or attachments


On 3/16/20 1:40 PM, twarren at nvidia.com wrote:
> From: Tom Warren <twarren at nvidia.com>
>
> Large kernels (>32MB) can fail to boot because they overwrite the FDT 
> address, corrupting the DTB. Stephen Warren had created a fix to 
> dynamically adjust the fdt/ramdisk/pxefile/kernel addr vars at boot 
> time for T186, which allows a large kernel to load and boot.

That was actually done to support holes in the RAM map; it's not actually required in order to support large kernels at all. We could just as easily directly modify the existing hard-coded load addresses.

> This is based on his commit, but applied to the tegraXXX-common.h 
> headers so it's used on all T186 and T210 Jetson boards. Note that 
> I've put the kernel 'size' param at 0x03000000, or 48MB, to leave room 
> for kernel growth. Current L4T kernels are running at about 32MB.

I had completely forgotten that we had the calculated env vars feature upstream already!

I thought we went with 96 or 128MB space for the kernel downstream, to make sure there'd "never" any future problem as the kernel grows?

But this patch seems OK for now I guess.
[Tom] Yes, we have a large (128MB) kernel size in downstream L4T U-Boot, but only because of the need to test GCOV kernels - I didn't think that excessive allocation was required upstream, so I backed it off to 48MB.  As to your point about just fixing the hard-coding of the kernel/ramdisk/fdt_addr_r in T210, I can do that, but it seemed more elegant and future-proof to use the calc env vars code you'd added for T186, plus it brings the two builds in sync, using the same allocation strategy for these 'load' vars.


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------