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] [day] [month] [year] [list]

Message-ID: <CALHNRZ86NjcNJhRJd+jtD_7fRTFJ2szPFAAN3HSad_xwnVrHWQ@mail.gmail.com>
Date: Fri, 24 Oct 2025 12:46:33 -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 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.

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