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: <00c5e342-50c7-44e6-89d3-3b879742c204@nvidia.com>
Date: Fri, 31 Oct 2025 10:47:22 +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 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