linux-kernel - Re: [PATCH RFC] 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: <CALHNRZ_7wChDsvpUnQHnOTT9VzT1Lgg8JYgg13AFV8Jg_3itwQ@mail.gmail.com>
Date: Mon, 26 May 2025 14:07:35 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: 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>, 
	Jonathan Hunter <jonathanh@...dia.com>, devicetree@...r.kernel.org, 
	linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] arm64: tegra: Add reserved-memory node for P3450

On Mon, May 26, 2025 at 2:06 PM Aaron Kling via B4 Relay
<devnull+webgeek1234.gmail.com@...nel.org> 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.
>
> Signed-off-by: Aaron Kling <webgeek1234@...il.com>
> ---
>  arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
> index 0ecdd7243b2eb1abba9adbe9a404b226c29b85ef..8fc995e71696f2ef5e662a21feb96ea771c7a53f 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
> +++ b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
> @@ -22,6 +22,12 @@ chosen {
>                 stdout-path = "serial0:115200n8";
>         };
>
> +       reserved-memory {
> +               #address-cells = <2>;
> +               #size-cells = <2>;
> +               ranges;
> +       };
> +
>         memory@...00000 {
>                 device_type = "memory";
>                 reg = <0x0 0x80000000 0x1 0x0>;
>
> ---
> base-commit: 0ff41df1cb268fc69e703a08a57ee14ae967d0ca
> change-id: 20250526-p3450-mts-bug-02394af31f0a
>
> Best regards,
> --
> Aaron Kling <webgeek1234@...il.com>

This was sent as an RFC to see if there are any better solutions to
this problem. Mts in l4t r32 for t210 tries to copy the training data
to the reserved ram location provided by the kernel dt. But if that
node doesn't exist, it somehow corrupts that dt, causing later stage
boot stages and the kernel itself to fail. Since software support for
this hardware is EOL, no fix for the bug can be expected. The normal
Linux boot flow on this hardware involves placing the downstream dt in
both the bootloader-dtb and kernel-dtb slots, allowing mts to work,
then u-boot loading whatever dt the kernel expects. However, my use
for Android does not need u-boot, as nvidia's cboot can load a
standard android boot image without the extra complexity of additional
boot stages. And I would prefer to keep complexity to a minimum. It
should be noted that this affects p2371-2180 using the L4T bootloader
as well, but since I am using the Android bootloader there, I sidestep
the issue.

Are there any thoughts on how to handle this problem? I know that it
is typically undesirable to add broken bootloader workarounds to the
kernel dt. But it would be preferable to have a fix upstream, instead
of having to carry various workarounds in downstream forks.

Sincerely,
Aaron Kling