Hey GBAtemp community!
I've been working on unbricking a used Switch Lite for several days now. I've made a lot of progress but I'm stuck on one specific error that I can't solve on my own. I've done extensive research and tried everything I can think of. Would really appreciate help from someone with experience in MMC Rebuilds on Mariko + FW 22.0.0.
---
CONSOLE DETAILS
- Device: Nintendo Switch Lite (Hoag), SKU 83 - Hoag - Vali - Retail
- SoC: T210B01 (Mariko)
- Modchipped - modchip works perfectly, hekate 6.5.3 boots without issues
- Firmware: 22.0.0 (23 burnt fuses, confirmed in hekate Console Info > HW & Fuses)
- eMMC: Samsung BJTD4R, Estimated Life A: 100% B: 100%, Reserved Used: Normal - hardware is completely healthy
- RAM: Samsung LPDDR4X 4GB
- Display: InnoLux 2J055IA-27A
---
HOW IT STARTED
I bought this Switch Lite used. The seller told me it couldn't boot into CFW or OFW - it always hung at the Nintendo Switch logo. hekate loaded perfectly via the modchip, so the boot chain was intact. After extensive testing (Stock sysMMC, OFW, CFW sysMMC - all three hung at the logo), I concluded the SYSTEM partition was corrupted. No NAND backup existed.
---
MMC REBUILD - WHAT I DID
Step 1: Key dumping
- Dumped prod.keys using Lockpick_RCM v1.9.18 (Kofysh fork, supports FW 22.0.0)
- Result: 231 prod keys found, master_key_15 confirmed (= FW 22.0.0)
- Dumped Mariko Partials via Lockpick "Dump Mariko Partials" option
- Result: partialaes.keys written to sd:/switch/
Step 2: EmmcHaccGen (latest GUI version)
- Both prod.keys AND partialaes.keys placed in the same folder
- Settings: ExFAT Support ON, Enable AutoRCM OFF, Generate Mariko Firmware ON
- Tool confirmed "Copied boot.bis" during generation (partialaes.keys was detected and used)
- Firmware: 22.0.0 confirmed by the tool
- "SD card prepared successfully! Files copied to E:\"
Step 3: TegraExplorer 4.2.0
- Browse SD > MMCRebuild > SystemRestoreV3.te > Restore Both
- Confirmation screen showed: Restore BIS: 1, Restore SYSTEM: 1, Restoring onto: SYSMMC
- Completed successfully: BOOT0, BOOT1, BCPKG2-1 through BCPKG2-4, all at 100%
Step 4: SystemWipe
- Ran SystemWipe > Wipe SYSMMC to clean the USER partition
---
SYSTEM PARTITION VERIFICATION
Verified via TegraExplorer > Browse EMMC > SYSTEM:
- bis:/saveMeta present
- bis:/Contents present
- bis:/Contents/registered: 119 NCA files across 3 pages
- bis:/save present
- BIS keys are WORKING - TegraExplorer can fully decrypt and read the SYSTEM partition
This confirms the BIS key restoration worked correctly at the privileged level.
---
THE ERROR
Every single boot attempt (CFW sysMMC, Stock sysMMC, OFW) results in:
A fatal error occurred when running Atmosphère.
Program ID: 0100000000000005
Error Desc: std::abort() called (0xffe)
Report saved to /atmosphere/fatal_errors/report_*.bin
Press POWER to reboot.
Note: Before the MMC rebuild, the console hung AT the Nintendo Switch logo. After the rebuild, it now gets PAST the logo and then crashes with this error - so there is definite progress, but we're not there yet.
---
FATAL ERROR BINARY ANALYSIS
I decoded the report_*.bin file manually using Python:
- Magic: AFE2
- Abort code: 0x0FFE
- Program ID: 0x0100000000000005 (fs module)
- PC: 0x00000077D0A04080
- SFCO result at offset 0x378: 0x00206002
- Module: 2 (fs)
- Description: 4144
- Nintendo error code: 2002-4144
- Critical finding: "spl:" string found in backtrace at offset 0x308
- This means the crash occurs during an SPL (Security Platform Layer) call originating from the fs module
Interpretation: The fs module calls SPL for what appears to be a BIS key or AES storage operation. Something unexpected happens (result 2002-4144 = likely UnexpectedInAesStorage or similar), causing fs to call std::abort(0xffe).
Key observation: TegraExplorer CAN read the SYSTEM partition using BIS keys in privileged mode, but the OS-level fs module aborts in userspace during an SPL call. This suggests the issue is not with the BIS key data itself, but with how SPL handles key operations in the OS userspace context after the NAND rebuild.
---
EVERYTHING I HAVE ALREADY TRIED
- Full SYSTEM + BIS restore via SystemRestoreV3.te (Restore Both, BIS:1 + SYSTEM:1 confirmed)
- BIS-only restore separately (confirmed BIS:1 on confirmation screen)
- SYSTEM-only restore separately
- SystemWipe to clean USER partition
- sys-patch v1.6.2.3 (impeeza fork - includes the erpt fix for latest Atmosphère)
- Included partialaes.keys alongside prod.keys in EmmcHaccGen, regenerated and re-restored everything
- Atmosphère 1.11.2 + hekate 6.5.3 (latest available versions)
- atmosphere/config/system_settings.ini with enable_all_generic_patches = u8!0x1
---
MY QUESTIONS
1. Is error 2002-4144 with "spl:" in the backtrace a known issue for EmmcHaccGen rebuilds specifically on Mariko + FW 22.0.0?
2. Is there something that EmmcHaccGen does not generate for FW 22.0.0 that causes the fs module to fail at the SPL key operation level? (For example a missing save structure, missing NCM index, or incorrect key area in BOOT0?)
3. Is there a specific exefs_patch or system_settings.ini option that bypasses the check causing result 2002-4144?
4. Should I try a different tool such as NAND Fix Pro or a donor NAND approach instead?
5. Could this be an Atmosphère 1.11.x bug specific to Mariko + FW 22.0.0 on a rebuilt NAND, and if so, is there a workaround?
I am attaching the full fatal_error report .bin file below. Thank you very much in advance - this console is SO close to working. hekate, the modchip, and the NAND hardware are all fully functional. It's just this one specific fs initialization step that's failing.
I've been working on unbricking a used Switch Lite for several days now. I've made a lot of progress but I'm stuck on one specific error that I can't solve on my own. I've done extensive research and tried everything I can think of. Would really appreciate help from someone with experience in MMC Rebuilds on Mariko + FW 22.0.0.
---
CONSOLE DETAILS
- Device: Nintendo Switch Lite (Hoag), SKU 83 - Hoag - Vali - Retail
- SoC: T210B01 (Mariko)
- Modchipped - modchip works perfectly, hekate 6.5.3 boots without issues
- Firmware: 22.0.0 (23 burnt fuses, confirmed in hekate Console Info > HW & Fuses)
- eMMC: Samsung BJTD4R, Estimated Life A: 100% B: 100%, Reserved Used: Normal - hardware is completely healthy
- RAM: Samsung LPDDR4X 4GB
- Display: InnoLux 2J055IA-27A
---
HOW IT STARTED
I bought this Switch Lite used. The seller told me it couldn't boot into CFW or OFW - it always hung at the Nintendo Switch logo. hekate loaded perfectly via the modchip, so the boot chain was intact. After extensive testing (Stock sysMMC, OFW, CFW sysMMC - all three hung at the logo), I concluded the SYSTEM partition was corrupted. No NAND backup existed.
---
MMC REBUILD - WHAT I DID
Step 1: Key dumping
- Dumped prod.keys using Lockpick_RCM v1.9.18 (Kofysh fork, supports FW 22.0.0)
- Result: 231 prod keys found, master_key_15 confirmed (= FW 22.0.0)
- Dumped Mariko Partials via Lockpick "Dump Mariko Partials" option
- Result: partialaes.keys written to sd:/switch/
Step 2: EmmcHaccGen (latest GUI version)
- Both prod.keys AND partialaes.keys placed in the same folder
- Settings: ExFAT Support ON, Enable AutoRCM OFF, Generate Mariko Firmware ON
- Tool confirmed "Copied boot.bis" during generation (partialaes.keys was detected and used)
- Firmware: 22.0.0 confirmed by the tool
- "SD card prepared successfully! Files copied to E:\"
Step 3: TegraExplorer 4.2.0
- Browse SD > MMCRebuild > SystemRestoreV3.te > Restore Both
- Confirmation screen showed: Restore BIS: 1, Restore SYSTEM: 1, Restoring onto: SYSMMC
- Completed successfully: BOOT0, BOOT1, BCPKG2-1 through BCPKG2-4, all at 100%
Step 4: SystemWipe
- Ran SystemWipe > Wipe SYSMMC to clean the USER partition
---
SYSTEM PARTITION VERIFICATION
Verified via TegraExplorer > Browse EMMC > SYSTEM:
- bis:/saveMeta present
- bis:/Contents present
- bis:/Contents/registered: 119 NCA files across 3 pages
- bis:/save present
- BIS keys are WORKING - TegraExplorer can fully decrypt and read the SYSTEM partition
This confirms the BIS key restoration worked correctly at the privileged level.
---
THE ERROR
Every single boot attempt (CFW sysMMC, Stock sysMMC, OFW) results in:
A fatal error occurred when running Atmosphère.
Program ID: 0100000000000005
Error Desc: std::abort() called (0xffe)
Report saved to /atmosphere/fatal_errors/report_*.bin
Press POWER to reboot.
Note: Before the MMC rebuild, the console hung AT the Nintendo Switch logo. After the rebuild, it now gets PAST the logo and then crashes with this error - so there is definite progress, but we're not there yet.
---
FATAL ERROR BINARY ANALYSIS
I decoded the report_*.bin file manually using Python:
- Magic: AFE2
- Abort code: 0x0FFE
- Program ID: 0x0100000000000005 (fs module)
- PC: 0x00000077D0A04080
- SFCO result at offset 0x378: 0x00206002
- Module: 2 (fs)
- Description: 4144
- Nintendo error code: 2002-4144
- Critical finding: "spl:" string found in backtrace at offset 0x308
- This means the crash occurs during an SPL (Security Platform Layer) call originating from the fs module
Interpretation: The fs module calls SPL for what appears to be a BIS key or AES storage operation. Something unexpected happens (result 2002-4144 = likely UnexpectedInAesStorage or similar), causing fs to call std::abort(0xffe).
Key observation: TegraExplorer CAN read the SYSTEM partition using BIS keys in privileged mode, but the OS-level fs module aborts in userspace during an SPL call. This suggests the issue is not with the BIS key data itself, but with how SPL handles key operations in the OS userspace context after the NAND rebuild.
---
EVERYTHING I HAVE ALREADY TRIED
- Full SYSTEM + BIS restore via SystemRestoreV3.te (Restore Both, BIS:1 + SYSTEM:1 confirmed)
- BIS-only restore separately (confirmed BIS:1 on confirmation screen)
- SYSTEM-only restore separately
- SystemWipe to clean USER partition
- sys-patch v1.6.2.3 (impeeza fork - includes the erpt fix for latest Atmosphère)
- Included partialaes.keys alongside prod.keys in EmmcHaccGen, regenerated and re-restored everything
- Atmosphère 1.11.2 + hekate 6.5.3 (latest available versions)
- atmosphere/config/system_settings.ini with enable_all_generic_patches = u8!0x1
---
MY QUESTIONS
1. Is error 2002-4144 with "spl:" in the backtrace a known issue for EmmcHaccGen rebuilds specifically on Mariko + FW 22.0.0?
2. Is there something that EmmcHaccGen does not generate for FW 22.0.0 that causes the fs module to fail at the SPL key operation level? (For example a missing save structure, missing NCM index, or incorrect key area in BOOT0?)
3. Is there a specific exefs_patch or system_settings.ini option that bypasses the check causing result 2002-4144?
4. Should I try a different tool such as NAND Fix Pro or a donor NAND approach instead?
5. Could this be an Atmosphère 1.11.x bug specific to Mariko + FW 22.0.0 on a rebuilt NAND, and if so, is there a workaround?
I am attaching the full fatal_error report .bin file below. Thank you very much in advance - this console is SO close to working. hekate, the modchip, and the NAND hardware are all fully functional. It's just this one specific fs initialization step that's failing.
