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 for Android: free password hash cracker in your pocket

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

Message-ID: <0049bde1-15e2-4c33-8de9-49f3df0d7650@nvidia.com>
Date: Tue, 28 Oct 2025 10:32:18 +0000
From: Jon Hunter <jonathanh@...dia.com>
To: Aaron Kling <webgeek1234@...il.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 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.

Jon

-- 
nvpublic