[PATCH RFC] arm64: tegra: Add reserved-memory node for P3450

[PATCH RFC] arm64: tegra: Add reserved-memory node for P3450

[Aaron Kling via B4 Relay]

From: Aaron Kling <webgeek1234@gmail.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@gmail.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@80000000 {
 		device_type = "memory";
 		reg = <0x0 0x80000000 0x1 0x0>;

---
base-commit: 0ff41df1cb268fc69e703a08a57ee14ae967d0ca
change-id: 20250526-p3450-mts-bug-02394af31f0a

Best regards,
-- 
Aaron Kling <webgeek1234@gmail.com>

Re: [PATCH RFC] arm64: tegra: Add reserved-memory node for P3450

[Aaron Kling]

On Mon, May 26, 2025 at 2:06 PM Aaron Kling via B4 Relay
<devnull+webgeek1234.gmail.com@kernel.org> wrote:
>
> From: Aaron Kling <webgeek1234@gmail.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@gmail.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@80000000 {
>                 device_type = "memory";
>                 reg = <0x0 0x80000000 0x1 0x0>;
>
> ---
> base-commit: 0ff41df1cb268fc69e703a08a57ee14ae967d0ca
> change-id: 20250526-p3450-mts-bug-02394af31f0a
>
> Best regards,
> --
> Aaron Kling <webgeek1234@gmail.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

Re: [PATCH RFC] arm64: tegra: Add reserved-memory node for P3450

[Aaron Kling]

On Mon, May 26, 2025 at 2:07 PM Aaron Kling <webgeek1234@gmail.com> wrote:
>
> On Mon, May 26, 2025 at 2:06 PM Aaron Kling via B4 Relay
> <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> >
> > From: Aaron Kling <webgeek1234@gmail.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@gmail.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@80000000 {
> >                 device_type = "memory";
> >                 reg = <0x0 0x80000000 0x1 0x0>;
> >
> > ---
> > base-commit: 0ff41df1cb268fc69e703a08a57ee14ae967d0ca
> > change-id: 20250526-p3450-mts-bug-02394af31f0a
> >
> > Best regards,
> > --
> > Aaron Kling <webgeek1234@gmail.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.

Friendly reminder about this question.

Aaron

Re: [PATCH RFC] arm64: tegra: Add reserved-memory node for P3450

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3121 bytes --]

On Mon, May 26, 2025 at 02:07:35PM -0500, Aaron Kling wrote:
> On Mon, May 26, 2025 at 2:06 PM Aaron Kling via B4 Relay
> <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> >
> > From: Aaron Kling <webgeek1234@gmail.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@gmail.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@80000000 {
> >                 device_type = "memory";
> >                 reg = <0x0 0x80000000 0x1 0x0>;
> >
> > ---
> > base-commit: 0ff41df1cb268fc69e703a08a57ee14ae967d0ca
> > change-id: 20250526-p3450-mts-bug-02394af31f0a
> >
> > Best regards,
> > --
> > Aaron Kling <webgeek1234@gmail.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.

Given that these are all standard nodes I think it's fine to include
this.

I'll pick this up later on.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH RFC] arm64: tegra: Add reserved-memory node for P3450

[Nicolas Chauvet]

Le jeu. 3 juil. 2025 à 13:00, Thierry Reding
<thierry.reding@gmail.com> a écrit :
>
> On Mon, May 26, 2025 at 02:07:35PM -0500, Aaron Kling wrote:
> > On Mon, May 26, 2025 at 2:06 PM Aaron Kling via B4 Relay
> > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > >
> > > From: Aaron Kling <webgeek1234@gmail.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.

Is there any particular reason why this applies on jetson-nano but not
jetson-tx1 (or any other l4t based boards ?)
I wonder if it would be enough to boot an upstream kernel with the l4t
bootloader (and no chainloaded upstream u-boot) as I cannot do the
other way for some reason (using fedora based upstream u-boot cannot
boot downstream l4t kernel anymore)

Thanks for the hints.

Re: [PATCH RFC] arm64: tegra: Add reserved-memory node for P3450

[Aaron Kling]

On Thu, Jul 3, 2025 at 11:24 AM Nicolas Chauvet <kwizart@gmail.com> wrote:
>
> Le jeu. 3 juil. 2025 à 13:00, Thierry Reding
> <thierry.reding@gmail.com> a écrit :
> >
> > On Mon, May 26, 2025 at 02:07:35PM -0500, Aaron Kling wrote:
> > > On Mon, May 26, 2025 at 2:06 PM Aaron Kling via B4 Relay
> > > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > > >
> > > > From: Aaron Kling <webgeek1234@gmail.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.
>
> Is there any particular reason why this applies on jetson-nano but not
> jetson-tx1 (or any other l4t based boards ?)

I answered that in my first reply to this patch. This does also apply
to p2371-2180, aka the Jetson TX1 devkit, but I don't need it for my
use case because it is supported by the android bootloader. To my
knowledge, there are not any other supported t210 devices that use the
l4t bootloader. And this is not a problem on other archs. If there's a
desire, I can replicate this to p2371-2180 and send a v2 without the
rfc tag. Probably better to do so for consistency anyways.

> I wonder if it would be enough to boot an upstream kernel with the l4t
> bootloader (and no chainloaded upstream u-boot) as I cannot do the
> other way for some reason (using fedora based upstream u-boot cannot
> boot downstream l4t kernel anymore)

Mmm, I'm not sure. I can boot a mainline kernel on the l4t bootloader
without u-boot after this patch. But my use case is android. I've also
booted a simple busybox initramfs to do non-android verification of
changes. But I've not booted a full Linux distro.

Aaron

Re: [PATCH RFC] arm64: tegra: Add reserved-memory node for P3450

[Aaron Kling]

On Thu, Jul 3, 2025 at 11:40 AM Aaron Kling <webgeek1234@gmail.com> wrote:
>
> On Thu, Jul 3, 2025 at 11:24 AM Nicolas Chauvet <kwizart@gmail.com> wrote:
> >
> > Le jeu. 3 juil. 2025 à 13:00, Thierry Reding
> > <thierry.reding@gmail.com> a écrit :
> > >
> > > On Mon, May 26, 2025 at 02:07:35PM -0500, Aaron Kling wrote:
> > > > On Mon, May 26, 2025 at 2:06 PM Aaron Kling via B4 Relay
> > > > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > > > >
> > > > > From: Aaron Kling <webgeek1234@gmail.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.
> >
> > Is there any particular reason why this applies on jetson-nano but not
> > jetson-tx1 (or any other l4t based boards ?)
>
> I answered that in my first reply to this patch. This does also apply
> to p2371-2180, aka the Jetson TX1 devkit, but I don't need it for my
> use case because it is supported by the android bootloader. To my
> knowledge, there are not any other supported t210 devices that use the
> l4t bootloader. And this is not a problem on other archs. If there's a
> desire, I can replicate this to p2371-2180 and send a v2 without the
> rfc tag. Probably better to do so for consistency anyways.
>
> > I wonder if it would be enough to boot an upstream kernel with the l4t
> > bootloader (and no chainloaded upstream u-boot) as I cannot do the
> > other way for some reason (using fedora based upstream u-boot cannot
> > boot downstream l4t kernel anymore)
>
> Mmm, I'm not sure. I can boot a mainline kernel on the l4t bootloader
> without u-boot after this patch. But my use case is android. I've also
> booted a simple busybox initramfs to do non-android verification of
> changes. But I've not booted a full Linux distro.

Reminder about this series since it wasn't picked up in the recent
staging for 6.17-rc1. Should I mirror the change to p2371-2180 in a
new patchset or should this get picked up as is?

Aaron

Re: [PATCH RFC] arm64: tegra: Add reserved-memory node for P3450

[Aaron Kling]

On Mon, Jul 14, 2025 at 12:39 AM Aaron Kling <webgeek1234@gmail.com> wrote:
>
> On Thu, Jul 3, 2025 at 11:40 AM Aaron Kling <webgeek1234@gmail.com> wrote:
> >
> > On Thu, Jul 3, 2025 at 11:24 AM Nicolas Chauvet <kwizart@gmail.com> wrote:
> > >
> > > Le jeu. 3 juil. 2025 à 13:00, Thierry Reding
> > > <thierry.reding@gmail.com> a écrit :
> > > >
> > > > On Mon, May 26, 2025 at 02:07:35PM -0500, Aaron Kling wrote:
> > > > > On Mon, May 26, 2025 at 2:06 PM Aaron Kling via B4 Relay
> > > > > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > > > > >
> > > > > > From: Aaron Kling <webgeek1234@gmail.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.
> > >
> > > Is there any particular reason why this applies on jetson-nano but not
> > > jetson-tx1 (or any other l4t based boards ?)
> >
> > I answered that in my first reply to this patch. This does also apply
> > to p2371-2180, aka the Jetson TX1 devkit, but I don't need it for my
> > use case because it is supported by the android bootloader. To my
> > knowledge, there are not any other supported t210 devices that use the
> > l4t bootloader. And this is not a problem on other archs. If there's a
> > desire, I can replicate this to p2371-2180 and send a v2 without the
> > rfc tag. Probably better to do so for consistency anyways.
> >
> > > I wonder if it would be enough to boot an upstream kernel with the l4t
> > > bootloader (and no chainloaded upstream u-boot) as I cannot do the
> > > other way for some reason (using fedora based upstream u-boot cannot
> > > boot downstream l4t kernel anymore)
> >
> > Mmm, I'm not sure. I can boot a mainline kernel on the l4t bootloader
> > without u-boot after this patch. But my use case is android. I've also
> > booted a simple busybox initramfs to do non-android verification of
> > changes. But I've not booted a full Linux distro.
>
> Reminder about this series since it wasn't picked up in the recent
> staging for 6.17-rc1. Should I mirror the change to p2371-2180 in a
> new patchset or should this get picked up as is?

Reminder about this question.

Aaron

Re: [PATCH RFC] arm64: tegra: Add reserved-memory node for P3450

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2783 bytes --]

On Thu, Jul 31, 2025 at 04:37:46PM -0500, Aaron Kling wrote:
> On Mon, Jul 14, 2025 at 12:39 AM Aaron Kling <webgeek1234@gmail.com> wrote:
> >
> > On Thu, Jul 3, 2025 at 11:40 AM Aaron Kling <webgeek1234@gmail.com> wrote:
> > >
> > > On Thu, Jul 3, 2025 at 11:24 AM Nicolas Chauvet <kwizart@gmail.com> wrote:
> > > >
> > > > Le jeu. 3 juil. 2025 à 13:00, Thierry Reding
> > > > <thierry.reding@gmail.com> a écrit :
> > > > >
> > > > > On Mon, May 26, 2025 at 02:07:35PM -0500, Aaron Kling wrote:
> > > > > > On Mon, May 26, 2025 at 2:06 PM Aaron Kling via B4 Relay
> > > > > > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > > > > > >
> > > > > > > From: Aaron Kling <webgeek1234@gmail.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.
> > > >
> > > > Is there any particular reason why this applies on jetson-nano but not
> > > > jetson-tx1 (or any other l4t based boards ?)
> > >
> > > I answered that in my first reply to this patch. This does also apply
> > > to p2371-2180, aka the Jetson TX1 devkit, but I don't need it for my
> > > use case because it is supported by the android bootloader. To my
> > > knowledge, there are not any other supported t210 devices that use the
> > > l4t bootloader. And this is not a problem on other archs. If there's a
> > > desire, I can replicate this to p2371-2180 and send a v2 without the
> > > rfc tag. Probably better to do so for consistency anyways.
> > >
> > > > I wonder if it would be enough to boot an upstream kernel with the l4t
> > > > bootloader (and no chainloaded upstream u-boot) as I cannot do the
> > > > other way for some reason (using fedora based upstream u-boot cannot
> > > > boot downstream l4t kernel anymore)
> > >
> > > Mmm, I'm not sure. I can boot a mainline kernel on the l4t bootloader
> > > without u-boot after this patch. But my use case is android. I've also
> > > booted a simple busybox initramfs to do non-android verification of
> > > changes. But I've not booted a full Linux distro.
> >
> > Reminder about this series since it wasn't picked up in the recent
> > staging for 6.17-rc1. Should I mirror the change to p2371-2180 in a
> > new patchset or should this get picked up as is?

Sorry, this somehow didn't show up in my list of things to look at in
patchwork. Yes, please add another patch that adds this on Jetson TX1 so
that we handle this uniformly everywhere.

Thanks,
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]