Re: [PATCH v2 1/2] arm64: tegra: Add reserved-memory node for P3450

[Jon Hunter]

On 24/10/2025 18:46, Aaron Kling wrote:
> On Fri, Oct 24, 2025 at 11:16 AM Jon Hunter <jonathanh@xxxxxxxxxx> wrote:
> > On 04/08/2025 04:14, Aaron Kling via B4 Relay wrote:
> > > From: Aaron Kling <webgeek1234@xxxxxxxxx>
> > >
> > > 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