I was asked by @vwadekar to raise issues here. See:
opened 06:40AM - 20 Sep 25 UTC
I recently began transferring my project to using v2.12 for t210, t186, and t194… . And my tests with t210 failed to boot. On both the l4t r32.7.6 boot stack and the android rel-shield-r one. So I began stepping backwards to through release tags to find the last working tag for the arch. And found that it was v2.7. Three years ago.
Next I started bisecting to find where the breakage occurred. 0fe7b9f2bcdf754c483399c841e5f0ec71e53ef3 broke the arch during the v2.8 development cycle. Then 40a4e2d84c38ffae899eaa2c33c1e280312919cf fixed that during the v2.9 dev cycle. However, f8a35797b919d8ea041480bd5eb2a334e7056e0b quickly broke things again. cb6c8efc4f2dd951b2b51801a12ba1755d49fe79 was supposed to fix that, but it actually doesn't. I get send_smc errors spammed in the boot log and boot never completes. However, that doesn't even matter because before that was merged, 0b9f05fcaea069bff6894d99ec5babc4be29ca67 landed which prevents t210 from even loading tf-a enough to start logging. End result: v2.9 doesn't boot for two separate reasons. And nothing changed from then until now.
If I revert cb6c8efc4f2dd951b2b51801a12ba1755d49fe79, 0b9f05fcaea069bff6894d99ec5babc4be29ca67, and f8a35797b919d8ea041480bd5eb2a334e7056e0b on top of v2.12, t210 boots as expected. This is not a valid solution however, because it reverts an intentional change to meet spec and it also breaks the other tegra platforms.
<br/>
This all raises a big question for me. Are the tegra platforms maintained at all? I looked at using tf-a release tags, expecting that the platforms were being verified and confirmed stable. Tegra210, Tegra186, and Tegra194 are listed in docs as supported. However:
a) Tegra210 hasn't even booted for three years.
b) Tegra186 throws mmu faults galore, causing display corruption during boot and likely other issues. And the [maintainer said](https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/35535/1#message-e4cfa0537335d6d88de06352eab731eff5ea4eb7) that Tegra186 support was developed against an internal bootloader that was never released to the public, so it has never worked right. And since that platform is EOL, it is unlikely the closed source updates will ever be released.
c) Tegra194 seems to work okay, but with the condition of the other two archs, my confidence is waning.
d) As a related note, it appears that Nvidia has no intention of pushing support for the newer platforms such as Tegra234 and Tegra264 and intends to only support those in downstream forks with no commit history. Which makes it near impossible to unify back to a single repo for supporting multiple archs inside a project.
So my question is: Is there any intention to maintain tegra support in upstream tf-a? If not, then the illusion that it is needs to be removed. Mark the platforms as unmaintained, so any potential users know to expect to put in work to make things usable. Or remove the platforms entirely.
See the opening post of that issue for more details. One of the two issues I resolved with:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/43279
The other issue is still not resolved. Using tf-a v2.12 with 43279 applied, the boot log spams:
[0021.478] send_smc: failed (ret=-1)
and boot never progresses. I have not yet found a proper fix for this. I am only able boot by reverting cb6c8ef and f8a3579 . Which is not a mergeable fix.
hello Steel01,
it’s not supported, as you can see.. JetPack 4 Reaches End of Life .