I have both an OLED Switch with a bad APU and also another v1/unpatched NS Switch that likely has a good APU but various other issues. I’m tempted to try to swap the APU (and paired NAND) from the NS and install it into the OLED Switch to see if I can make one good Switch. Bonus points if I end up with an unpatched OLED Switch as a result.
The CPU markings on both are ODNX10-A1, which supports that they may be compatible. The NAND package is also the same, although unfortunately it would require reballing on the OLED which adds more work. The biggest question for me would be whether the software installed on the NAND is configured only to work with a certain system (OLED vs NS), or if those features are automatically detected at runtime.
Although, even if the OFW fails to load, even getting Linux or Android to work on it though would be interesting and better than nothing. If it becomes unpatched, that might also leave some options open to try to correct software issues.
Before I invest a fair amount of time to try this, does anyone know of any reasons why this wouldn’t work?
This is an interesting thought but I don’t think it will work. CPU/GPU buck reg is very different on OLED so odds are pretty high on this not working as there is likely nothing in NAND of your unpatched that is even aware how to communicate with it (at least not properly as it’s expecting a different IC)
Then, while i haven’t confirmed this a second time. I’m very sure Ram manufacturer is strict so if they’re different bewteen the two that could cause problems also.
I haven’t checked but haven’t they ditched the custom asic for something more standard (relating to GC) if yes, it’s likely a very different pinout
That all being said. If they’re both done for as is, then it might be fun to try and/or see what blows up and who knows, maybe the OS is smart enough to switch comms over etc depending on whiat CPU/GPU reg (and the numerous other IC’s present on OLED which aren’t on regular rev) is in use.
If you have another regular rev donor board. I’d be swapping the SoC and EMMC over to that instead though.
Thanks for the thoughts! I didn’t consider the custom ASIC possibility. That likely reduces the odds of this working. Perhaps I can do a spot test of some of the connections to see if they match up when compared to another donor board I have. As you mentioned, I also think it’s more likely that the software isn’t intelligent enough to detect the hardware.
I ordered a NAND stencil from China which gives me a few weeks to contemplate this likely bad idea. I also don’t have much to lose, so I might still try it … but would significantly lower my expectations/hope prior to doing so Either way, I’d probably learn something in the process.
Good catch, @Calvin ! I started writing this while contemplating taking a patched SoC which I was looking at and then changed my post to ask about an unpatched Switch before submitting. That’s an important observation though, since it suggests that I might have more luck with a patched switch relative to an unpatched Switch since at least the SoC part number would match.
Another interesting observation I had in the meantime is that Hekate has code to handle Switches flashed with either Erista and Mariko, so there is some concept of the eMMC being flashed for a specific hardware configuration. But, it doesn’t appear to have any significant code to specifically handle OLED, but it does support it. I’m also reading that OLED is basically considered Mariko. That might suggest that the OLED is basically compatible with a patched Mariko-flashed eMMC.
Hmmm… I think I might try it (with a patched donor).
I think the biggest issue here is the data held on the EMMC and the subsequent execution by the CPU/s. I don’t imagine they accounted for OLED when releasing Lite/Mariko rev boards (atleast not originally). I think at best it would require heavy modification of the boot0/1 partitions and at worst also the data held on the other partitions which you won’t be able to do without decrypting the data.
While I do think this would be fun experiment, SoC reballs can be tricky at the best of times (especially if you haven’t done one before) So it might just be best to wait until you get another rev donor board to transplant the SoC and EMMC onto. Though as I say, this would be fun experiment regardless
That’s another good call, @Severence . Even best case scenario, that the software can auto-detect the hardware and act accordingly, I’d probably still need a donor eMMC that had a software version released after the OLED Switch.
Even despite everything suggesting I shouldn’t try, curiosity got the best of me today. I had the OLED Switch that had a SoC that would get super hot as soon as the battery was plugged in. I thought the SoC was bad, so I stole/installed a Mariko (ODNX10-A1) APU from a V2 Switch donor. My hope was that it would go into RCM (even if I couldn’t inject a payload), so I could at least verify I’m on the right track. Instead, the behavior was exactly the same with the new SoC, with the SoC overheating almost immediately. Not sure I learned anything from this exercise, since I haven’t ruled out if there’s actually an issue with the board causing the overheating instead of the SoC.
And then I got another not-so-bright idea with completely different hardware. I took an Erista / V1 SoC from a heavily liquid damaged Switch and installed it in a Mariko / V2 motherboard. The Mariko motherboard seemed mostly in tact despite having some eMMC issues. What’s really interesting is that the device entered RCM and I was able to successfully inject a payload (with a 0x7000 response). Although, there was no display. Given the SoC had significant liquid damage, I’m not confident the GPU wasn’t already damaged, but the fact that I can inject a payload suggests that there might be some compatibility.
Not sure where I plan to go with all this, but I find it interesting and maybe I’ll discover some techniques to make more effective use of all the donor parts I have.
Shame. Nice work on trying though. Does sound like a potential other board issue at play like you say
I would actually expect Hekate to run happily in this case - I think the real issue in this scenario is the OS working (due to the CPU/GPU reg differences amongst other things) - you see Hekate isn’t utilising the bigger brother CPU/GPU on the SoC at any stage (to the best of my knowledge) and as a result doesn’t enable the CPU/GPU reg, I don’t even think Hekate supports enabling of high current charging - It’s best to think of it as an alternative bootloader. So I don’t see why Hekate wouldn’t work completely in this scenario
That all being said, perhaps you have a display related issue in your second case?
and who knows, maybe the OS is smart enough to switch comms over etc depending on whiat CPU/GPU reg (and the numerous other IC’s present on OLED which aren’t on regular rev) is in use.
Either way, I’d probably learn something in the process.
I would actually expect Hekate to run happily in this case - I think the real issue in this scenario is the OS working (due to the CPU/GPU reg differences amongst other things) - you see Hekate isn’t utilising the bigger brother CPU/GPU on the SoC at any stage (to the best of my knowledge) and as a result doesn’t enable the CPU/GPU reg, I don’t even think Hekate supports enabling of high current charging - It’s best to think of it as an alternative bootloader. So I don’t see why Hekate wouldn’t work completely in this scenario