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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALHNRZ_odC8jcu9h_ZKJ9+449pBhmYfXF=vBkprxYkqXhabM9A@mail.gmail.com>
Date: Wed, 29 Oct 2025 14:54:30 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Jon Hunter <jonathanh@...dia.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Thierry Reding <thierry.reding@...il.com>, 
	devicetree@...r.kernel.org, linux-tegra@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] arm64: tegra: Add reserved-memory node for P3450

On Tue, Oct 28, 2025 at 5:32 AM Jon Hunter <jonathanh@...dia.com> wrote:
>
>
> On 24/10/2025 18:46, Aaron Kling wrote:
> > On Fri, Oct 24, 2025 at 11:16 AM Jon Hunter <jonathanh@...dia.com> wrote:
> >>
> >>
> >> On 04/08/2025 04:14, Aaron Kling via B4 Relay wrote:
> >>> From: Aaron Kling <webgeek1234@...il.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