Lemme try to do a dumb short version that doesn't take me an hour to write when I should be heading to the gym. It's 2:25 eastern right now, so check the timestamp on this thing to see how successful I was.
Basically, my prior assumptions are that REDACTED is a Switch 2, with a T239, T239's GPU is still what we see in the Nvidia hack, the Linux driver's are still accurate, and our guesses about CPU/Memory Controller/FDE all hold up. I think I'm/we're right about all of it, but it's worth looking at alternatives.
It's a good idea to periodically challenge our assumptions, as there's always a danger of assumptions being treated as facts if they're repeated enough.
CPU wise, I think that's where we're most likely to be wrong. We've been assuming that Drake uses the A78C, because that's a variant of the A78 (the CPU in Orin) which can have 8 CPU clusters, which we know Drake has. It's also the most advanced CPU that is backward compatible with the CPU in the Switch.
But the more it seems like Nintendo might use emulation for backwards compat, and the more Drake's design seems distinct from Orin, it seems like the CPU might be a later iteration. I think A78C is probably the best choice for Nintendo, and the other CPUs probably launched too late, so I still feel confident, but it's not impossible.
The A78C CPU is an interesting one, because it's something many people (including myself) treat as guaranteed even though we have zero evidence for it. I think one of the reasons is that the A78 is both the worst-case scenario and not that much worse than the best-case scenario, so the level of CPU performance we can expect doesn't really change that much if we swap it out for A710 or A715.
That said, I do think it's worth going through the alternatives (of which there are more than you would think). The first and obvious ones are the newer generations of ARM's consumer big cores, the A710 and A715. The A710 is a plausible option, both in terms of timescale and compatibility (ie AArch32 support). A715 is less likely, partly due to the lack of AArch32 support, which is something they could work around if they really wanted to, but also because of how new it is. The first phones using A715 cores have only just appeared in the last couple of months, which means it's actually a little bit newer than Ada. Given they decided to stick with Ampere over Ada when designing T239, it would be an odd choice to simultaneously go bleeding edge on the CPU design.
Another set of CPU cores that I wouldn't completely rule out are the Neoverse cores. While on the surface they don't seem a good fit for a gaming SoC, Nvidia may have a preference for them. Grace uses Neoverse V2 cores, and is the first chip to do so, suggesting Nvidia is working closely with ARM on implementing the Neoverse line. Additionally, both Atlan and now Thor have been described as using "Grace" or "Grace-Next" CPU cores, indicating that they'll move to the Neoverse line for their automotive SoCs as well.
Anandtech suggests that Thor will use an automotive version of the Poseidon core, which is due to become the Neoverse V3. If Nvidia's plan is to use Neoverse cores exclusively going forward, then that may extend to T239. The Neoverse V series, like the Cortex X series, are unlikely because they're designed for higher power draws, but the Neoverse N series would be a reasonable fit. The Neoverse N2, which is based on the same architecture as the A710, would likely work just fine for Nintendo's use-case.
Finally, to play devil's advocate, it's worth noting that we don't
strictly know that all 8 cores use the same architecture. The Linux commit that tells us there are 8 CPU cores tells us they're in the same cluster, however ARM's DynamIQ clusters support multiple core types per cluster, and in mobile designs it's typical to combine all cores in the same cluster, to allow for efficient migration between cores. The Snapdragon 8 Gen 2 actually has four different core types in a single DynamIQ cluster. The reason I think this is unlikely for T239 is that the CPUFreq driver that was updated to support T239 only appears to support a single policy per cluster. That is, the min and max frequency, DVFS tables, etc, would be shared across all cores in a cluster. This would make the driver, as it currently is, incompatible with a heterogeneous CPU design. It's possible that this is only a partial implementation, and further changes will be made to support heterogenous clusters, however in that case I would question the value of this first commit, as almost every line in it would have to be changed again to support heterogeneous clusters. I would also think it would make much more sense in that case to create a CPUFreq driver specifically for T239, rather than shoehorning it into the driver for the homogeneous Xavier and Orin CPUs.
The Linux driver is next up.
It wouldn't be the first time that an in-progress SOC gets into the kernel. But again, the evidence is strong that these driver updates are post-tape-out and thus likely to be up to date. But it's not-even-beta software, it's not guaranteed to be correct, and it's not a complete driver stack. I think it's likely that the info there is up to date. But misinterpretations or missing pieces seem completely possible.
It's worth noting here as well that
Orin's support was initially upstreamed to Linux before silicon was available, although in that case it was made very clear that it was pre-tape-out, and that what was being added was support for the VDK simulation platform.
I think the GPU info is pretty solid. Again, it's all about timing. The Lapsus$ hack is from February, tape out potentially happened as early as March. But I don't think it's inconceivable that, once hardware starts being manufactured, that there is some element of floor-sweeping/binning, and that the final hardware doesn't have all the TPCs active. That seems unlikely, simply because Ampere is a well understood GPU design at this point, but we also don't know what the process node is, so we don't have a real sense what sort of yields Nintendo might be dealing with.
T239 is clearly designed for Nintendo, and it doesn't match either company's history to get as far as tape out and then pull out. But there are a couple indications that Nvidia might have alternate plans for T239 - a LinkedIn post referring to developing the chip for "game consoles/tablets", the Linux drivers. Could Nintendo have dropped the project and Nvidia continued? Yes. But it is as likely as Bigfoot existing.
And finally, is REDACTED a Switch 2? Well, yeah. Nintendo is gonna make another handheld, come on. T239 is clearly a mobile device, but it has the controllers necessary to plug into an external screen the same way that Switch does. It's a new hybrid... unless Nintendo is making a VR device, or had a last minute rethink of REDACTED and decided to repurpose the chip, while keeping Switch around. Which I think is as likely as Bigfoot and the Loch Ness monster being friends
The main question I've been asking myself is if there's any evidence that T239 is intended for other customers alongside Nintendo. The support being added to L4T (and upstreamed to the Linux kernel) suggests that it's not an exclusive product, and in theory could mean it would be taped out before Nintendo requires it (or even if Nintendo cancelled the device intended to use it). That would require at least one significant customer other than Nintendo being lined up for it, though, and I can't see any realistic situation where that's the case. The lack of modules like the PVA makes it unsuitable for automotive use-cases, which is effectively Nvidia's only other market for SoCs outside Nintendo. The only other possible customers I can imagine would be in ARM Windows laptops, but that's still a very small niche, and the lack of games compiled for ARM would negate Nvidia's biggest advantage, GPU performance. The use of ARM big cores (ie A78/A710/etc.) would also put them behind the likes of Qualcomm in CPU performance, who are already behind Intel and AMD.