linux-kernel - Re: [PATCH v2 0/4] memory: tegra210-emc: Support Device Tree EMC Tables

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: <CALHNRZ8fOe_tQvybemvBa4yjS7JyXpAA1ksP_Dmx_9w=KXb2ig@mail.gmail.com>
Date: Thu, 3 Jul 2025 12:11:39 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Thierry Reding <thierry.reding@...il.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Jonathan Hunter <jonathanh@...dia.com>, Rob Herring <robh@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, linux-kernel@...r.kernel.org, 
	linux-tegra@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 0/4] memory: tegra210-emc: Support Device Tree EMC Tables

On Thu, Jul 3, 2025 at 5:37 AM Thierry Reding <thierry.reding@...il.com> wrote:
>
> On Mon, Jun 30, 2025 at 02:26:06PM -0500, Aaron Kling wrote:
> > On Wed, May 28, 2025 at 12:41 PM Aaron Kling <webgeek1234@...il.com> wrote:
> > >
> > > On Thu, May 8, 2025 at 7:48 AM Thierry Reding <thierry.reding@...il.com> wrote:
> > > >
> > > > On Thu, May 08, 2025 at 07:27:52AM -0500, Aaron Kling wrote:
> > > > [...]
> > > > > The devices I'm talking about are not yet end of life, so it is
> > > > > physically possible for them to get a bootloader update to conform to
> > > > > the existing mainline model. But I'm just one guy trying to do 3rd
> > > > > party support for these devices, I can't affect what Nvidia does with
> > > > > the signed bootloader on these devices. I'd love to be able to swap
> > > > > out an open source bootloader on these, but the secure boot setup
> > > > > prevents that.
> > > >
> > > > I've reached out to our Android team internally to see if there's
> > > > anything we can realistically do about this.
> > > >
> > > > Thierry
> > >
> > > Thierry, has there been any feedback about this?
> > >
> >
> > Reminder about this question. Has there been any response from the
> > Nvidia Android team? Or do I/we need to continue pursuing independent
> > solutions?
>
> There's been no decision either way, but it's fairly complicated because
> the changes involved here are fairly large, even if the impact should be
> fairly low.
>
> If all else fails, do we have other alternatives? I suspect that adding
> some sort of shim that runs prior to the kernel won't work because the
> EMC tables just aren't accessible from the bootloader anymore. Would it
> entail parsing the entirety of the DT EMC tables and transcribing them
> into some memory and pass that to the kernel?

I see three options in general

1) Change the bootloader to conform with existing mainline standards
2) Merge support for the existing bootloader method to mainline
3) Have a chainloaded bootloader / shim that converts the tables

I submitted this series because I was trying to avoid 3. On most
devices, I don't need u-boot and I'm trying to avoid it. Due to
another issue on p2571 (nvtboot ignores the bootloader dtb when the
cvm board id is 2530 and uses the kernel dtb, making it to where I
can't replace the kernel dtb like I can everywhere else), I will
likely have to use u-boot. But for p2897, p3425, and the devkits I can
still avoid it.

If 1 fails and 3 is undesirable, then 2 is the only option I see.
Which based on responses seems pretty unlikely too. If u-boot becomes
the only option, I should be able to write something to read the dt
tables and write out a reserved memory region. I just want to exhaust
every other possibility before adding that complexity to the boot
flow.

Aaron