From: Aaron Kling <webgeek1234@gmail.com>

The Tegra210 L4T bootloader ram training will corrupt the in-ram kernel
dt if no reserved-memory node exists. This prevents said bootloader from
being able to boot a kernel without this node, unless a chainloaded
bootloader loads the dt. Add the node to eliminate the requirement for
extra boot stages.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
index 0ecdd7243b2eb1abba9adbe9a404b226c29b85ef..8fc995e71696f2ef5e662a21feb96ea771c7a53f 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
@@ -22,6 +22,12 @@ chosen {
 		stdout-path = "serial0:115200n8";
 	};
 
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+	};
+
 	memory@80000000 {
 		device_type = "memory";
 		reg = <0x0 0x80000000 0x1 0x0>;

-- 
2.50.1

On 04/08/2025 04:14, Aaron Kling via B4 Relay wrote:
> From: Aaron Kling <webgeek1234@gmail.com>
> 
> The Tegra210 L4T bootloader ram training will corrupt the in-ram kernel
> dt if no reserved-memory node exists. This prevents said bootloader from
> being able to boot a kernel without this node, unless a chainloaded
> bootloader loads the dt. Add the node to eliminate the requirement for
> extra boot stages.

I test this platform and don't see any problems. I assume that this 
would prevent the board from booting.

What bootloader are you using? Is this from a particular L4T release?

Jon

-- 
nvpublic

On Fri, Oct 24, 2025 at 11:16 AM Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
> On 04/08/2025 04:14, Aaron Kling via B4 Relay wrote:
> > From: Aaron Kling <webgeek1234@gmail.com>
> >
> > The Tegra210 L4T bootloader ram training will corrupt the in-ram kernel
> > dt if no reserved-memory node exists. This prevents said bootloader from
> > being able to boot a kernel without this node, unless a chainloaded
> > bootloader loads the dt. Add the node to eliminate the requirement for
> > extra boot stages.
>
> I test this platform and don't see any problems. I assume that this
> would prevent the board from booting.
>
> What bootloader are you using? Is this from a particular L4T release?

Please see the longer description of my setup on the revision v1 patch
here [0]. I am specifically using the cboot prebuilt from L4T r32.6.1
as it is the last version to support usb input in the fastboot menu
[1]. The rest of the boot stack is from L4T r32.7.6. The partition
layout xml is here [2], which requires setting odmdata bit 11 to allow
reading bootloader partitions off the sdcard. There is no u-boot
involved, only cboot.

I've had another report of the same issue, on a pure L4T r32.7.6 boot
stack as well. The Nvidia downstream u-boot won't copy
external-memory-controller nodes, namely the memory-region ones, from
the cboot dtb to the kernel dtb unless the phandles match. Nv-tegra
gitles isn't working right now, so I can't link directly, but on
branch l4t/l4t-r32.7.6-v2020.04, file arch/arm/mach-tegra/dt-edit.c,
see line 31. Which means that such only works if u-boot destination
FDT is the downstream dtb. Using a mainline dtb causes the
memory-region dt tables to not be available, thus the emc kernel
driver fails to probe and emc clock stays stuck at 204MHz on
p3450/p3541. Hence the user from the report trying to cut u-boot out
of the mix in order to get emc scaling. And then hit this issue.

You were able to boot with a mainline dtb on the DTB partition and a
kernel on LNX, without u-boot and without this change? I have not been
able to do this. The boot flow will get past nvtboot_cpu, but falls
apart inside cboot due to the corrupted in-ram dtb, never getting to
kernel logs.

Aaron

[0] https://lore.kernel.org/all/CALHNRZ_7wChDsvpUnQHnOTT9VzT1Lgg8JYgg13AFV8Jg_3itwQ@mail.gmail.com/
[1] https://forums.developer.nvidia.com/t/cboot-xusb-support-broken-since-r32-7-1/243534
[2] https://github.com/LineageOS/android_device_nvidia_porg/blob/f52038d326ef67002185dbe04e9ff1070db2be4c/flash_package/flash_android_t210_max-spi_sd_p3448.xml

On 24/10/2025 18:46, Aaron Kling wrote:
> On Fri, Oct 24, 2025 at 11:16 AM Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>>
>> On 04/08/2025 04:14, Aaron Kling via B4 Relay wrote:
>>> From: Aaron Kling <webgeek1234@gmail.com>
>>>
>>> The Tegra210 L4T bootloader ram training will corrupt the in-ram kernel
>>> dt if no reserved-memory node exists. This prevents said bootloader from
>>> being able to boot a kernel without this node, unless a chainloaded
>>> bootloader loads the dt. Add the node to eliminate the requirement for
>>> extra boot stages.
>>
>> I test this platform and don't see any problems. I assume that this
>> would prevent the board from booting.
>>
>> What bootloader are you using? Is this from a particular L4T release?
> 
> Please see the longer description of my setup on the revision v1 patch
> here [0]. I am specifically using the cboot prebuilt from L4T r32.6.1
> as it is the last version to support usb input in the fastboot menu
> [1]. The rest of the boot stack is from L4T r32.7.6. The partition
> layout xml is here [2], which requires setting odmdata bit 11 to allow
> reading bootloader partitions off the sdcard. There is no u-boot
> involved, only cboot.
> 
> I've had another report of the same issue, on a pure L4T r32.7.6 boot
> stack as well. The Nvidia downstream u-boot won't copy
> external-memory-controller nodes, namely the memory-region ones, from
> the cboot dtb to the kernel dtb unless the phandles match. Nv-tegra
> gitles isn't working right now, so I can't link directly, but on
> branch l4t/l4t-r32.7.6-v2020.04, file arch/arm/mach-tegra/dt-edit.c,
> see line 31. Which means that such only works if u-boot destination
> FDT is the downstream dtb. Using a mainline dtb causes the
> memory-region dt tables to not be available, thus the emc kernel
> driver fails to probe and emc clock stays stuck at 204MHz on
> p3450/p3541. Hence the user from the report trying to cut u-boot out
> of the mix in order to get emc scaling. And then hit this issue.
> 
> You were able to boot with a mainline dtb on the DTB partition and a
> kernel on LNX, without u-boot and without this change? I have not been
> able to do this. The boot flow will get past nvtboot_cpu, but falls
> apart inside cboot due to the corrupted in-ram dtb, never getting to
> kernel logs.

Yes, I am using r32.5.1 currently (which was probably what was available 
at the time I enabled testing). But with this I am able to boot an 
upstream DTB with the upstream kernel using cboot (no u-boot). However, 
please note that I don't use the upstream DTB for the bootloaders (MB1, 
MB2, cboot, etc). I specify the kernel DTB in the 
/boot/extlinux/extlinux.conf file so only the kernel uses this.

Jon

-- 
nvpublic

On Tue, Oct 28, 2025 at 5:32 AM Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
> On 24/10/2025 18:46, Aaron Kling wrote:
> > On Fri, Oct 24, 2025 at 11:16 AM Jon Hunter <jonathanh@nvidia.com> wrote:
> >>
> >>
> >> On 04/08/2025 04:14, Aaron Kling via B4 Relay wrote:
> >>> From: Aaron Kling <webgeek1234@gmail.com>
> >>>
> >>> The Tegra210 L4T bootloader ram training will corrupt the in-ram kernel
> >>> dt if no reserved-memory node exists. This prevents said bootloader from
> >>> being able to boot a kernel without this node, unless a chainloaded
> >>> bootloader loads the dt. Add the node to eliminate the requirement for
> >>> extra boot stages.
> >>
> >> I test this platform and don't see any problems. I assume that this
> >> would prevent the board from booting.
> >>
> >> What bootloader are you using? Is this from a particular L4T release?
> >
> > Please see the longer description of my setup on the revision v1 patch
> > here [0]. I am specifically using the cboot prebuilt from L4T r32.6.1
> > as it is the last version to support usb input in the fastboot menu
> > [1]. The rest of the boot stack is from L4T r32.7.6. The partition
> > layout xml is here [2], which requires setting odmdata bit 11 to allow
> > reading bootloader partitions off the sdcard. There is no u-boot
> > involved, only cboot.
> >
> > I've had another report of the same issue, on a pure L4T r32.7.6 boot
> > stack as well. The Nvidia downstream u-boot won't copy
> > external-memory-controller nodes, namely the memory-region ones, from
> > the cboot dtb to the kernel dtb unless the phandles match. Nv-tegra
> > gitles isn't working right now, so I can't link directly, but on
> > branch l4t/l4t-r32.7.6-v2020.04, file arch/arm/mach-tegra/dt-edit.c,
> > see line 31. Which means that such only works if u-boot destination
> > FDT is the downstream dtb. Using a mainline dtb causes the
> > memory-region dt tables to not be available, thus the emc kernel
> > driver fails to probe and emc clock stays stuck at 204MHz on
> > p3450/p3541. Hence the user from the report trying to cut u-boot out
> > of the mix in order to get emc scaling. And then hit this issue.
> >
> > You were able to boot with a mainline dtb on the DTB partition and a
> > kernel on LNX, without u-boot and without this change? I have not been
> > able to do this. The boot flow will get past nvtboot_cpu, but falls
> > apart inside cboot due to the corrupted in-ram dtb, never getting to
> > kernel logs.
>
> Yes, I am using r32.5.1 currently (which was probably what was available
> at the time I enabled testing). But with this I am able to boot an
> upstream DTB with the upstream kernel using cboot (no u-boot). However,
> please note that I don't use the upstream DTB for the bootloaders (MB1,
> MB2, cboot, etc). I specify the kernel DTB in the
> /boot/extlinux/extlinux.conf file so only the kernel uses this.

So the problem is with memory training, which is run in
TBC/nvtboot_cpu. Iiuc, which is a limited understanding, mts primes
with the dt emc tables from the bootloader dtb from RP1. Then if dt
emc tables exist for the kernel dtb from DTB, it will copy the trained
data to there. And on newer l4t versions, I don't know which version
that started on, it will copy to a reserved memory location and set
the location in the kernel dtb from DTB. This piece will fail if a
reserved-memory node doesn't already exist in the kernel dtb from DTB.
Causing the cascading failure described before.

For Android, cboot just boots an android boot image on LNX. There's no
u-boot, extlinux, etc etc. I've got the downstream dtb from RP1, since
the bootloader only works with the downstream layout. Then I've got
the mainline dtb from DTB for handoff to the mainline kernel.

Extlinux isn't useful for my usecase of android, but I'm in contact
with people using Linux distros. So I'm curious if your setup copies
the reserved-memory nodes to the extlinux FDT. Like, does the emc
driver initialize properly and allow scaling?

Aaron

On 29/10/2025 19:54, Aaron Kling wrote:

...

> So the problem is with memory training, which is run in
> TBC/nvtboot_cpu. Iiuc, which is a limited understanding, mts primes
> with the dt emc tables from the bootloader dtb from RP1. Then if dt
> emc tables exist for the kernel dtb from DTB, it will copy the trained
> data to there. And on newer l4t versions, I don't know which version
> that started on, it will copy to a reserved memory location and set
> the location in the kernel dtb from DTB. This piece will fail if a
> reserved-memory node doesn't already exist in the kernel dtb from DTB.
> Causing the cascading failure described before.
> 
> For Android, cboot just boots an android boot image on LNX. There's no
> u-boot, extlinux, etc etc. I've got the downstream dtb from RP1, since
> the bootloader only works with the downstream layout. Then I've got
> the mainline dtb from DTB for handoff to the mainline kernel.
> 
> Extlinux isn't useful for my usecase of android, but I'm in contact
> with people using Linux distros. So I'm curious if your setup copies
> the reserved-memory nodes to the extlinux FDT. Like, does the emc
> driver initialize properly and allow scaling?

Looking at the boot logs it does not appear so ...

  OF: reserved mem: Reserved memory: No reserved-memory node in the DT

We can apply your fix, but may clarify in the commit message the exact 
scenario where you see the bootloader 'corrupt the in-ram kernel dt' 
because yes this is probably only seen for specific cases.

Thanks
Jon

-- 
nvpublic