Three mysterious none working game consoles in a row.
It is a patched V1 Erista.
I bought this Switch with symtoms for an typical Wifi ic issue. No boot past the Switch logo (second boot screen)
Charging symbol is displayed and the console is fast charging (with 5V and original 15V charger)
From a known good board I harvest Wifi, m92t36, 1x max77621 (left from the SoC) and changed this components one by one. But the behavior didn’t change.
I installed a RP2040 hwfly and launched linux. Wifi and BT are working fine. On Hekate I dump the whole emmc and restore it to another emmc. No changes with the new emmc.
Atmosphere is also not booting. It shows the both Atmos boot screens but then displays a panic message.
The benchmark for both emmcs was fine but at testing in the beginning but both emmc got the message in the end of the ~30 min read/write duration for dump and restore that the emmc is in slow mode. And in fact a new benchmark test shows a slower data rate. ~300 MiB/s → ~150 MiB/s. After cooldown the data rate goes up again.
Addional the touchscreen is not so responsive like I use to know. It is a tiny bit to slow and you often have to push a field twice or a bit longer to activate it.
Are there any memtest programs I could start from Hekate or Linux?
Any ideas are welcome.
Given that your seeing the slowdown (which i presume is out of the oridinary) on two different EMMC’s then it would suggest it’s the patient board/something on the board at fault.
Which unfortunately would get us to the next point - given the other issues your seeing with the touchscreen (assuming this isn’t a digitizer or GC PCB issue) which would be the next thing in the chain which has I/O in common, that being the SoC … I had one such case a long time ago, high current charging was present when USB connected and was basically acting like a switch which should work but wouldn’t clear the second boot logo, “rebuilt” FW, changed EMMC, replaced all components which could be potentially be at fault such as wifi IC, various passives which could cause the fault I think I even changed the Ram, CPU and GPU regs, PMIC etc etc and no cigar and ultimately put it down to the SoC given there wasn’t much else to replace… maybe it was a SoC joint related issue but gut told me there was something internally wrong with the SoC (though I don’t recall ever transferring the SoC to another board to confirm this)
Trouble is, without knowing the specifics of the Switch boot process after it clears the initial bootloader phase - which afaiui when you see the second logo you have done and your now into the OS loading phase (again just as far as I know) then it’s hard to know where to look. Could well just be some com line or general I/O not coming up (maybe from WIFI IC) which could just be a single joint issue under the SoC.
I think if the ram is being addressed and full capacity is shown in L4t and your not getting any crashes in L4t (for example doing something which consumes a lot of memory) then Ram is likely not your issue. Does memtest not work in L4t ubuntu? if no I would imagine you could probably run an app from the androidOS for switch?
Do you have any history of the the board? such as any signs or prior work and the like.
Also I’m guessing you changed the two caps as a matter of course to the laft of the SoC, which if i recall can cause symptoms like this
The history for this Switch is unknown. But the save data speaks for a little girl as owner.
The shield from the wifi ic and SoC where removed before and some little components resistors and caps south the SoC between max77621 and usb connector were missing. So there was a prior repair attempt.
I tested the two caps left of the SoC. The both lines have the resistance/diode mode values I would expect from those lines.
Funny thing: L4T isn’t turning on more. So I can not test Linux further. Something has changed from yesterday to today…
I will try a reflow. But I’m not very hopefull.
Yeah this is giving me SoC or SoC joint issue vibes. Might wanna try gentle pressure on both the SoC and Ram while attempting to boot into linux and see if anything changes. If it does then might be worth transferring the SoC over to another board as i find in these cases it’s usually the board itself which is toast. If no change at all, then probably it’s the SoC itself which is a goner.
I wouldn’t reflow if you see any change as in these cases where someone else has messed with the board and likely caused or furthered the issue and it’s more than likely if it does resolve the issue that the problem willl once again return later, and given the SoC’s sensitivity to heat - probably not worth the risk.
I don’t remember but if you can get biskeydump to load using the modchip it might be worth doing, for whatever reason it seems to promote/enable viewing of ram issues quite easily (either SoC input side or Ram itself) which is quite easy to see visually and alter with pressure for confirmation.
While pushing on the SoC during boot, the bootsequence alters a little bit. The logo screen doesn’t turn immediately off, after pressing the power button again. I have to hold it 10 sec before turning off.
So it maybe a contact problem under the SoC.
I will put the Switch beside and if I organized a working donor mainboard and some time over, I will try to swap the SoC to the donor board. The last two SoC swaps had been successfull but in the end, one didn’t survive the first day in kids hands (maybe dropped) and at the other the previous fault was transfered via the board. (I though it was a SoC related issue. :P)