On Mon, Jul 14, 2025 at 01:01:19AM -0500, Aaron Kling wrote: > On Thu, Jul 3, 2025 at 2:24 AM Thierry Reding <thierry.red...@gmail.com> > wrote: > > > > On Mon, Jun 30, 2025 at 01:48:28PM -0500, Aaron Kling wrote: > > > On Thu, May 29, 2025 at 3:53 AM Krzysztof Kozlowski <k...@kernel.org> > > > wrote: > > > > > > > > On 28/05/2025 19:35, Aaron Kling wrote: > > > > >>>> > > > > >>>> Friendly reminder to the Tegra maintainers about this question. > > > > >>>> > > > > >>> In lieu of a response from the Tegra subsystem maintainers, I can > > > > >>> only > > > > >>> hazard an assumption, Krzysztof. I presume the pstore carveout is > > > > >>> bootloader controlled because various stages of the boot stack can > > > > >>> dynamically allocate memory, and this became bootloader controlled > > > > >>> to > > > > >>> prevent any of those from overwriting pstore. I worry about > > > > >>> hardcoding > > > > >>> an address in the kernel dt, then finding out later that there's an > > > > >>> in-use configuration that overwrites or corrupts that section of ram > > > > >>> during boot. What are your thoughts on this? And is there any way > > > > >>> for > > > > >>> this patch to proceed? > > > > >> > > > > >> I haven't been able to find anything out about this yet. Generally > > > > >> it's > > > > >> difficult to get the bootloaders updated for these devices. Tegra194 > > > > >> and > > > > >> Tegra234 may be new enough to make an update eventually go into a > > > > >> release, but for Tegra186 and older, I honestly wouldn't hold my > > > > >> breath. > > > > >> > > > > >> Thierry > > > > > > > > > > Krzysztof, based on this response, is there any way or form that the > > > > > Tegra186 part of this could be submitted? I can drop the newer > > > > > platforms from this patch if Thierry can get a response to his other > > > > > reply about how the bootloader could conform. > > > > > > > > > I don't NAK it. Eventually it is up to platform maintainer if they > > > > accept known DTC warnings. > > > > > > > > Best regards, > > > > Krzysztof > > > > > > If the decision is up the the tegra maintainers, then Thierry, what's > > > your thoughts now? What is in this patch should be compatible with > > > existing l4t and android bootloaders. But it does add a few new dtb > > > check lines. > > > > I don't adding new DTC warnings, especially ones that we know up front > > we can never get rid of. The memory one is a notable exception because > > the system becomes unusable without it. > > > > ramoops is not in that same category. While it's certainly nice to have, > > I don't think it's critical enough to warrant that permanent exception. > > Where possible I think we need to work to address issues souch as this > > at the root and fix bootloaders to do the right thing. > > > > For any cases where we can't fix the bootloaders, I think that's > > something we have to live with. Having the support for this live in a > > fork is a fair compromise, I think. > > > > I know this is frustrating, and it's very painful for me personally > > because I initially set out to redress a lot of these things and failed > > to do so. > > > > However I can't justify accepting endless amounts of quirks upstream, > > all of which would set a bad precedent, just for the sake of things > > being upstream. > > > > Thierry > > Alright, so to make sure everything is on the same page, let me walk > through the archs. > > T210: This fits within dt check requirements afaik. If I send a v2 > with only t210, would that patch be acceptable? Though, I would like > to double check that my assumption about the arch is correct. The > downstream 4.9 kernel does allocations for ramoop I can't quite track > in the vendor code. I'm assuming that by matching what the downstream > kernel picks, that it's within a large carveout that the bootloader > will never touch. I've not seen any corruption in my use of it so far. > Is this a safe assumption?
I haven't looked into ramoops support at all yet, so I don't know how this is handled. If we can find out where exactly this memory is and that it's guaranteed to be static, then maybe we can hardcode this. If not, I don't think there's much of a chance to get anything in. > T186: Software support for this arch is eol, so what the bootloader > does cannot be changed. Presumably no other choice but to relegate to > a commit in a fork or out of tree patches. Sounds about right. > T194: Some software support still exists for this arch in L4T r35. Is > there any positive feedback on making bootloader changes to meet dt > check requirements, or is it too late in the cycle? > > T234: Still has active software support in L4T r36. But essentially > the same question as t194. We can probably fix things for these two generations. > T264: I assume whatever happens for t234 will be mirrored here. Yes. We do try to incrementally improve things on newer generations, so anything we fix for Tegra194/Tegra234 I expect will be done for Tegra264 and later chips, too. Thierry
signature.asc
Description: PGP signature
