Solved
Disclaimer: I'm not responsible for any damage related to the following guide
Redirecting to proper section:
NAND Rebuilding Guide
Update:
It's great that I managed to rebuild a bootable NAND and tried some games on it.
Other than not having a normal bootable OFW, it seems good.
In conclusion, I've used
brief/unexplained steps:
Original Post:
Thanks for reading.
Credit to all the payloads, software creators, and advices in this post and Unbricking Guide:
SciresM and the ReSwitched team for Atmosphere
CTCaer for Hekate
Shchmue for Lockpick_RCM
CaramelDunes for prodinfo_gen
SuchMemeManySkill for eMMC Hacc Gen
Rajkosto for HacDiskMount
Eliboa for NXNandManager
ignasurba for mmcblkNX
Balena for Balena Etcher
Redirecting to proper section:
NAND Rebuilding Guide
Update:
It's great that I managed to rebuild a bootable NAND and tried some games on it.
Other than not having a normal bootable OFW, it seems good.
In conclusion, I've used
brief/unexplained steps:
[(A) stands for things from good Switch; (D) from dead Switch; (O) for output files]
rawnand.bin (A) with its complete prod.keys (A) file from a good Switch
prod.keys (D) from bad Switch and added common master keys (source, 00 to 05) from good prod.keys (A)
prodinfo_gen.bin
OFW 12.0.2
mmcblknx: emmc chip reader. can flash BOOT1 and BOOT0 on linux
(Tried OFW 3.0.0 and 9.0.0 both failed)
Other files already on sdcard which I'm not so sure with the versions:
Atmosphere
Hekate & Nyx
then use
1. EmmcHaccGen v2.2.3
Building folders SAFE (O), SYSTEM (O), USER (O)
Building files BCPKG2-1 to BCPKG2-4 (O)
Building files boot.bis (O), BOOT0.bin(O), BOOT1.bin (O)
2. NxNandManager v5.0
Import a very limited prod.keys (D) file to output BIS keys (keys.dat (O))
Export decrypted PRODINFO.bin (A), PRODINFOF.bin (A), SAFE.bin (A), SYSTEM.bin (A), USER.bin (A)
3. prodinfo_gen.bin
Generate PRODINFO.bin (O) from PRODINFO.bin (A) with prod.keys (D)
4. HacDiskMount v1.0.5-5
Save BIS keys from keys.dat (O) for PRODINFO.bin, PRODINFOF.bin, SAFE.bin, SYSTEM.bin, USER.bin
Import PRODINFO.bin (O), PRODINFOF.bin (A), SAFE.bin (A), SYSTEM.bin (A), USER.bin (A), BCPKG2-1 to BCPKG2-4 (O)
Mount SAFE, SYSTEM, USER, and delete all of the content and filled with files in SAFE (O), SYSTEM (O), USER (O)
5. By mmcblknx / Hekate / SXOS
Flash / Restore BOOT0.bin(O), BOOT1.bin (O)
I tried to use both mmcblknx to flash them on a linux system
and Hekate EMMC restore
Both worked just fine even Hekate gave warning of mismatch of sizes, it's save to do for me.
boot with fusee-primary.bin
This may give an error and need to press power button to reboot once, then can boot into Atmosphere
If you encounter boot loop to Atmosphere splash screen / error screen, it's not normal
After repairing NAND, OFW 12.1.0 is installed using Daybreak
Atmosphere 0.20.1
Remember to use corresponding sigpatch
rawnand.bin (A) with its complete prod.keys (A) file from a good Switch
prod.keys (D) from bad Switch and added common master keys (source, 00 to 05) from good prod.keys (A)
prodinfo_gen.bin
OFW 12.0.2
mmcblknx: emmc chip reader. can flash BOOT1 and BOOT0 on linux
(Tried OFW 3.0.0 and 9.0.0 both failed)
Other files already on sdcard which I'm not so sure with the versions:
Atmosphere
Hekate & Nyx
then use
1. EmmcHaccGen v2.2.3
Building folders SAFE (O), SYSTEM (O), USER (O)
Building files BCPKG2-1 to BCPKG2-4 (O)
Building files boot.bis (O), BOOT0.bin(O), BOOT1.bin (O)
2. NxNandManager v5.0
Import a very limited prod.keys (D) file to output BIS keys (keys.dat (O))
Export decrypted PRODINFO.bin (A), PRODINFOF.bin (A), SAFE.bin (A), SYSTEM.bin (A), USER.bin (A)
3. prodinfo_gen.bin
Generate PRODINFO.bin (O) from PRODINFO.bin (A) with prod.keys (D)
4. HacDiskMount v1.0.5-5
Save BIS keys from keys.dat (O) for PRODINFO.bin, PRODINFOF.bin, SAFE.bin, SYSTEM.bin, USER.bin
Import PRODINFO.bin (O), PRODINFOF.bin (A), SAFE.bin (A), SYSTEM.bin (A), USER.bin (A), BCPKG2-1 to BCPKG2-4 (O)
Mount SAFE, SYSTEM, USER, and delete all of the content and filled with files in SAFE (O), SYSTEM (O), USER (O)
5. By mmcblknx / Hekate / SXOS
Flash / Restore BOOT0.bin(O), BOOT1.bin (O)
I tried to use both mmcblknx to flash them on a linux system
and Hekate EMMC restore
Both worked just fine even Hekate gave warning of mismatch of sizes, it's save to do for me.
boot with fusee-primary.bin
This may give an error and need to press power button to reboot once, then can boot into Atmosphere
If you encounter boot loop to Atmosphere splash screen / error screen, it's not normal
After repairing NAND, OFW 12.1.0 is installed using Daybreak
Atmosphere 0.20.1
Remember to use corresponding sigpatch
Original Post:
Questions about
"Uniqueness of NAND pairing with hardware"
As searched, all I know about Switch's hardware is that the NAND is paired with the hardware, and are not interchangeable with other units.
Now I haven't backed up my NAND, then the MMC chip somehow went faulty.
Even if I managed to get a chip, I cannot restore my NAND files on it, then the Switch is already bricked.
All I would like to know from creating this thread is that, which component actually causes the problems? And which components are uniquely bind to the NAND?
Now I have a Switch (A) with good MMC chip with it's NAND in good condition, and most parts of the Switch are good, but I just don't want to use this board anymore.
Another Switch (B) has a faulty MMC chip with no NAND backup done, and the unit is bricked.
If I want to swap MMC (A) to Switch (B) without rebuilding NAND, can I actually move some more components (such as APU) from (A) to (B) together, to make the NAND usable on (B) ?
Do we have enough knowledge about which components are responsible for the binding of NAND with hardware?
And at the end of all the thoughts, why is Nintendo doing this, that the MMC are not interchangable at all? Is there any good?
Isn't it easier for them to have the same (or nearly the same) NAND on all Switches.
If a clean NAND is installed on the MMC, the Switch starts to bind with the MMC afterwards. (The idea came from PSVita memory card)
"Uniqueness of NAND pairing with hardware"
As searched, all I know about Switch's hardware is that the NAND is paired with the hardware, and are not interchangeable with other units.
Now I haven't backed up my NAND, then the MMC chip somehow went faulty.
Even if I managed to get a chip, I cannot restore my NAND files on it, then the Switch is already bricked.
All I would like to know from creating this thread is that, which component actually causes the problems? And which components are uniquely bind to the NAND?
Now I have a Switch (A) with good MMC chip with it's NAND in good condition, and most parts of the Switch are good, but I just don't want to use this board anymore.
Another Switch (B) has a faulty MMC chip with no NAND backup done, and the unit is bricked.
If I want to swap MMC (A) to Switch (B) without rebuilding NAND, can I actually move some more components (such as APU) from (A) to (B) together, to make the NAND usable on (B) ?
Do we have enough knowledge about which components are responsible for the binding of NAND with hardware?
And at the end of all the thoughts, why is Nintendo doing this, that the MMC are not interchangable at all? Is there any good?
Isn't it easier for them to have the same (or nearly the same) NAND on all Switches.
If a clean NAND is installed on the MMC, the Switch starts to bind with the MMC afterwards. (The idea came from PSVita memory card)
Thanks for reading.
Credit to all the payloads, software creators, and advices in this post and Unbricking Guide:
SciresM and the ReSwitched team for Atmosphere
CTCaer for Hekate
Shchmue for Lockpick_RCM
CaramelDunes for prodinfo_gen
SuchMemeManySkill for eMMC Hacc Gen
Rajkosto for HacDiskMount
Eliboa for NXNandManager
ignasurba for mmcblkNX
Balena for Balena Etcher
Last edited by ewabc886,