Toggle sidebar

Hacking Hardware Patched V1 Switch – Purple screen in OFW, works fine in CFW

  • Thread starter Thread starter morganno
  • Start date Start date
  • Views Views 1,512
  • Replies Replies 8
M

morganno

Active Member
Newcomer
Level 4
Joined
Aug 7, 2018
Messages
33
Reaction score
5
Trophies
0
Age
50
XP
369
Country
France
Hi everyone,

I have a patched V1 Switch that a client gave me. It was stuck on the Nintendo Switch logo, and after checking, I found that the system partition was corrupted. So, I restored all partitions and completely reinstalled the firmware as I usually do.

Now, the console boots perfectly in CFW, and everything works fine (Wi-Fi, game cartridges, etc.). However, in OFW, I get a purple screen.

I initially thought it might be an issue with the BOOT0/BOOT1 partitions, so I reflashed them, but the problem persists. On OLED models, a purple screen can sometimes be caused by a faulty resistor on the CMD line of the EMMC, but in this case, it’s a patched V1.

I checked all the EMMC lines leading to the SoC, tested the resistors, and compared the diode mode values with another motherboard: everything is identical and within normal values. I even replaced the EMMC with a new one, but the issue remains the same: purple screen in OFW, while everything works fine in CFW.

Has anyone encountered this problem before or has any idea what might be preventing the OFW from booting?

Thanks in advance for your help!
 
No, it’s not an eFuse issue, because if the fuse count was incorrect (either higher or lower than expected), the screen would be completely black. But here, I have a purple screen, which is very strange.

Originally, the console was stuck on the Nintendo Switch logo and had never been modified. When I checked, I found that the system partition was corrupted. So, I restored the system partition, reinstalled everything, and recreated the firmware exactly matching the eFuse count.

I have 19 burned eFuses, which corresponds to firmware 17.0.0 to 18.1.0. I generated the firmware with EmmcHaccGen and installed version 18.1.0, which is fully compatible with this eFuse count.
 
It is usually a kernel panic when the Switch cannot read data during the boot process or while booting up the operating system.
Once that is up and running, you get nice error messages.

CFW only uses BOOT0 and BOOT1, after that it uses the SD card.
Maybe the backup that you are using already has this corruption in the System partition.
I recall there was a 4th partition besides BOOT0/1 and system. but maybe that only holds the recovery menu.
Not sure if we have tools to check that.
I read tat HacDiskMount will throw an error if you try to copy something that is corrupted.
Hekate should be able to show you that the partition table is valid.
If you don't mind, you could try a factory reset with the OFW.
That should format the emmc and mark bad parts of it.
Or try running the recovery menu. Sometimes Nintendo's own tools can actually fix things.
 
thesjaakspoiler said:
It is usually a kernel panic when the Switch cannot read data during the boot process or while booting up the operating system.
Once that is up and running, you get nice error messages.

CFW only uses BOOT0 and BOOT1, after that it uses the SD card.
Maybe the backup that you are using already has this corruption in the System partition.
I recall there was a 4th partition besides BOOT0/1 and system. but maybe that only holds the recovery menu.
Not sure if we have tools to check that.
I read tat HacDiskMount will throw an error if you try to copy something that is corrupted.
Hekate should be able to show you that the partition table is valid.
If you don't mind, you could try a factory reset with the OFW.
That should format the emmc and mark bad parts of it.
Or try running the recovery menu. Sometimes Nintendo's own tools can actually fix things.
Click to expand...
Thanks for your reply!

I have tested several methods to recreate and restore the partitions properly:

• Complete partition reconstruction: I recreated each partition one by one using a batch script on a brand-new EMMC, straight out of the box, with no partitions.

• Clean NAND flash: I used a RAW NAND from a donor console, decrypted each partition using its Prod.Keys, including the encrypted partitions:

• prodinfo.enc
• prodinfof.enc
• safe.enc
• system.enc
• user.enc

Then, I re-encrypted each partition with the console’s own keys before flashing the EMMC.

• Firmware regeneration: I generated a clean firmware using the latest version of EmmcHaccGen (previously I was using version 2.2.3) and reintegrated all BCPKG2 packages along with the prodinfo, system, user, and boot0/boot1 partitions.

• Flashing BOOT0/BOOT1: I reflashed BOOT0 and BOOT1 using BalenaEtcher and TegraExplorer (SystemRestoreV3).

• Testing with multiple EMMC modules: I tested different EMMC chips, and to rule out any issues, I set this console aside and tested these same EMMC chips on another console → everything worked perfectly.

At this point, I doubt it’s a storage (EMMC) issue. I have more reason to believe it’s a SoC problem, possibly related to the CMD line.

Thanks for your input! If you have any other suggestions, I’d appreciate it!
 
morganno said:
Thanks for your reply!

I have tested several methods to recreate and restore the partitions properly:

• Complete partition reconstruction: I recreated each partition one by one using a batch script on a brand-new EMMC, straight out of the box, with no partitions.

• Clean NAND flash: I used a RAW NAND from a donor console, decrypted each partition using its Prod.Keys, including the encrypted partitions:

• prodinfo.enc
• prodinfof.enc
• safe.enc
• system.enc
• user.enc

Then, I re-encrypted each partition with the console’s own keys before flashing the EMMC.

• Firmware regeneration: I generated a clean firmware using the latest version of EmmcHaccGen (previously I was using version 2.2.3) and reintegrated all BCPKG2 packages along with the prodinfo, system, user, and boot0/boot1 partitions.

• Flashing BOOT0/BOOT1: I reflashed BOOT0 and BOOT1 using BalenaEtcher and TegraExplorer (SystemRestoreV3).

• Testing with multiple EMMC modules: I tested different EMMC chips, and to rule out any issues, I set this console aside and tested these same EMMC chips on another console → everything worked perfectly.

At this point, I doubt it’s a storage (EMMC) issue. I have more reason to believe it’s a SoC problem, possibly related to the CMD line.

Thanks for your input! If you have any other suggestions, I’d appreciate it!
Click to expand...
how is the mod chip connected to emmc module? Have you checked the soldered point been worked with. i.e CMD, RST point.
FYI, if modchip is the nx style with rp2040 chip, the built-in resistor values may have effect on OFW boot as well
 
jkyoho said:
how is the mod chip connected to emmc module? Have you checked the soldered point been worked with. i.e CMD, RST point.
FYI, if modchip is the nx style with rp2040 chip, the built-in resistor values may have effect on OFW boot as well
Click to expand...
Thanks for your input!

This is what’s strange. I’m using a modchip similar to HWFY, which doesn’t require any direct soldering to the EMMC. The only soldered connections are on the CPU for the MOSFETs.

Even after completely removing the modchip, the screen remains purple.

Originally, the console had a corrupted system partition, meaning it passed BOOT0 and BOOT1, reached the Nintendo Switch logo, so Horizon OS was starting, but it remained stuck at that stage.

When I restored the SYSTEM partition, the console booted up without any issues. It was only when I tried to boot in original mode (OFW) that I encountered the purple screen. At that point, I thought: “What the hell is going on?”

I initially suspected that I might have damaged a resistor while handling the console. I took out the magnifier to check, but nothing looked abnormal. Then, I tested the CMD line resistance, which measures 4.2 kΩ, so it seems fine.

After that, I went through everything I explained earlier:

• Checked all the lines
• Tested with multiple EMMC modules
• Fully flashed all partitions
• Regenerated the firmware
• Tested without the modchip

Tomorrow, I will test with another modchip to see if that could be the issue, but honestly, based on my experience, I don’t think the chip is the problem.

As soon as I finish my tests, I will update you all with the results.

Thanks again for the suggestion! If anyone has other ideas, I’m open to suggestions
Post automatically merged:

I’ve run several tests, and here’s what I found:

• Changed the modchip → No change, still a purple screen.

• Replaced the resistor → No effect either.

• Updated the firmware to 19.0.1 using Daybreak → The update went through fine, and the fuse count is now 20 as expected.

• Rebooted in stock mode (OFW) → Still purple screen.

So, despite all these tests, the issue remains exactly the same.

If anyone has other ideas, I’m open to suggestions!
 
Last edited by morganno,
idk, I had a similiar issue once. Solderjob at the cpu had a lot of flux, und I think some copper went under the apu. I bathed the whole board in IPA, and washed it gently. Redid everything with wires (I used flex before) and it booted everything, like nothing ever happened.
 

Site & Scene News

Go to forum More news

Popular threads in this forum

Homebrew Homebrew game  Chrono Trigger - Switch port

Emulation Homebrew PS1/2 Emulator  ARMSX2-NX Initial Release

Homebrew Homebrew game  Half Life 2 (Source Engine) - Switch Port

Homebrew Homebrew game  GTA: Chinatown Wars - Switch port

Homebrew Homebrew game  Final Fantasy IV 3D Remake - Switch port

Homebrew Homebrew game  Lego Star Wars: The Complete Saga · Switch Port

Hacking Homebrew Tutorial  New Switch Modpack, NX-ModPack

Homebrew Homebrew game  Castlevania Symphony of the Night - Switch port