EmuMMC setup Win/Linux & Quadboot

eyeliner · Jun 19, 2019

TariqSoftDev said:
Take a look, windows has been up for a while.

Thanks, useful anonymous internet user.
It wasn't there before.

So you know, I've restored my NAND backup from a year ago (dead easy), but used your guide with my backup and wonderfully, it worked.

I'd give you a cool sticker if you were near me.

regnad said:
An unrelated question: will it be possible to create an emummc from our existing "dirty" nand while restoring our clean backed up pre-modding nand to the system? Or is it necessary to erase everything on the SD and create an emummc from scratch?

Yes. That's what most of us are doing. I am, anyway.

Cyan · Jun 19, 2019

regnad said:
will it be possible to create an emummc from our existing "dirty" nand while restoring our clean backed up pre-modding nand to the system?

You have to make a new dump with hekate from your "dirty" console first. then you'll have to format the SD you want to use with that dump as you'll have to write the bin somewhere on it. (or resize the FAT32 and put the dump at the end)

TariqSoftDev said:
It messes with the switch somtimes if something gets changed, the switch looks at the first partition for the norm storage;

That's not a problem, because the "unallocated" area at the beginning of the SD is NOT a partition. the FAT32 will always be the "first partition" used by the console, the first and only one defined partition in the MBR table.

the way you made the guide, you actually created and allocated partitions in the MBR, (you even format them to FAT32, but it's not necessary, unformatted partition work too). But it can be an issue to have more than one partition defined on SD card's MBR.
burning the dump on raw sector numbers instead of using a partition table for a now corrupted partition format might not be a good idea. OS will ask to format them (unless you de-allocate a letter). Of course defining a partition in the MBR is useful to get the starting sector value.
but that's just the way I see it, everyone can do the way they prefer, as long as they understand it better

my opinion is that it's better to not allocate them in the MBR and have only one FAT32 partition there. the emu partition can be in raw, at a designated stating sector without the need of a partition table for it.
at least, not in MBR's 0x1BE. like I said, we could store the starting sector in one of the unused area of the MBR, only the tool will know it. The SD with the emu on it should never be used with the OFW online so it's not a big problem to fear it would be easily detected. not worse than having the partition not taking the full SD size.

nopo · Jun 19, 2019

TariqSoftDev said:
Windows cmd:
copy /b BOOT0+BOOT1+rawnand.bin.00+rawnand.bin.01+rawnand.bin.02+rawnand.bin.03+rawnand.bin.04+rawnand.bin.05+rawnand.bin.06+rawnand.bin.07+rawnand.bin.08+rawnand.bin.09+rawnand.bin.10+rawnand.bin.11+rawnand.bin.12+rawnand.bin.13+rawnand.bin.14 emummc.bin

for this part my rawnand only goes up to 11 parts but I did it on FW 6.0. also I have blown fuses so how will using this backup work will it put me on 8.0.1 or what

TariqSoftDev · Jun 19, 2019

nopo said:
for this part my rawnand only goes up to 11 parts but I did it on FW 6.0. also I have blown fuses so how will using this backup work will it put me on 8.0.1 or what

11 parts?, something's not right; redump it.

--------------------- MERGED ---------------------------

Cyan said:
You have to make a new dump with hekate from your "dirty" console first. then you'll have to format the SD you want to use with that dump as you'll have to write the bin somewhere on it. (or resize the FAT32 and put the dump at the end)

That's not a problem, because the "unallocated" area at the beginning of the SD is NOT a partition. the FAT32 will always be the "first partition" used by the console, the first and only one defined partition in the MBR table.

the way you made the guide, you actually created and allocated partitions in the MBR, (you even format them to FAT32, but it's not necessary, unformatted partition work too). But it can be an issue to have more than one partition defined on SD card's MBR.
burning the dump on raw sector numbers instead of using a partition table for a now corrupted partition format might not be a good idea. OS will ask to format them (unless you de-allocate a letter). Of course defining a partition in the MBR is useful to get the starting sector value.
but that's just the way I see it, everyone can do the way they prefer, as long as they understand it better

my opinion is that it's better to not allocate them in the MBR and have only one FAT32 partition there. the emu partition can be in raw, at a designated stating sector without the need of a partition table for it.
at least, not in MBR's 0x1BE. like I said, we could store the starting sector in one of the unused area of the MBR, only the tool will know it. The SD with the emu on it should never be used with the OFW online so it's not a big problem to fear it would be easily detected. not worse than having the partition not taking the full SD size.

De-Allocate in win partition manager.
Once you DD the EmuMMC the partition is RAW.
With this method leaving EmuMMC as first causes issues with HOS reading it.
EmuMMC is only formatted to FAT32 so it can be recognized by DD for windows.

Cyan · Jun 19, 2019

Deallocate means deleting the partition ? or you talk only about the letter?

if it's only about the letter then it's why it create problems with the switch. if you DD the emuMMC over an existing partition, it doesn't delete the partition information in the MBR (0x1BE on sector0 holds up to 4 primary partitions information: it keeps the active flag/chs start, type, chs end, LBA and size). in windows that's not a problem if you unassigned the letter, but you said it could be an issue on the switch if the FAT32 wasn't the first partition. I just said it's an issue only if the MBR retain the partition information because it's still marked as FAT32 even though it's emuMMC, so it tried to mount it. you can just delete the partition so it is seen as unallocated instead of keeping it as a FAT32 with unassigned letter.

4 solutions :
- keep the emuMMC at the end (like you said in your guide, so it's fine!)
in case you want to close/expand FAT32 one day:
- create a FAT32 near the end and write emuMMC before FAT32 but without creating a partition info on the MBR,
- create multiple FAT32, but then delete the partition where you installed emuMMC so it is not marked as FAT32 anymore!
- create multiple partition, and once you are done writing the emuMMC to SD you can change 0x1BE of sector 0 to put the FAT32 on the first of the 4 primary slots , even if it's not the first partition. it's a little hacky to do it manually, but it works.
that's just idea for developers, and to answer to users who asked. I don't want to mess with your guide or with user's who don't understand what I'm saying. it's probably just for DarkMatterCore

TariqSoftDev · Jun 19, 2019

Cyan said:
Deallocate means deleting the partition ? or you talk only about the letter?

if it's only about the letter then it's why it create problems with the switch. if you DD the emuMMC over an existing partition, it doesn't delete the partition information in the MBR (0x1BE on sector0 holds up to 4 primary partitions information: it keeps the active flag/chs start, type, chs end, LBA and size). in windows that's not a problem if you unassigned the letter, but you said it could be an issue on the switch if the FAT32 wasn't the first partition. I just said it's an issue only if the MBR retain the partition information because it's still marked as FAT32 even though it's emuMMC, so it tried to mount it. you can just delete the partition so it is seen as unallocated instead of keeping it as a FAT32 with unassigned letter.

4 solutions :
- keep the emuMMC at the end (like you said in your guide, so it's fine!)
in case you want to close/expand FAT32 one day:
- create a FAT32 near the end and write emuMMC before FAT32 but without creating a partition info on the MBR,
- create multiple FAT32, but then delete the partition where you installed emuMMC so it is not marked as FAT32 anymore!
- create multiple partition, and once you are done writing the emuMMC to SD you can change 0x1BE of sector 0 to put the FAT32 on the first of the 4 primary slots , even if it's not the first partition. it's a little hacky to do it manually, but it works.
that's just idea for developers, and to answer to users who asked. I don't want to mess with your guide or with user's who don't understand what I'm saying. it's probably just for DarkMatterCore

I see what you're saying, guess you're right but best not to complicate the guide any more else it may become a fest of "help I'm stuck at x step"

ScarletDreamz · Jun 19, 2019

So.. If you have a clean nand backup, and decide to use it as your EmuMMC, booting it via Atmosphere wont it trigger something? like, signature patches, or something at boot?
like, booting it via atmosphere dosnt it trigger something on the nintendo side? even if you use it as a clean system, like, nothing installed, nor run homebrew, just as clean system, does it send something that doesnt match?

pretty much the question is, booting atmosphere send some kind of telemetry?

healthyboy · Jun 19, 2019

I get the following error when trying to write the emummc.bin onto my SD card

Error writing file: 87 The parameter is incorrect
0
1+0 records in
0+0 records out

Anyone know what the problem is?

Cyan · Jun 19, 2019

you used linux or windows? which command did you type?

ScarletDreamz said:
So.. If you have a clean nand backup, and decide to use it as your EmuMMC, booting it via Atmosphere wont it trigger something? like, signature patches, or something at boot?

yes, that's why emuMMC on switch is to be used differently than how users are used to with other consoles.
on most consoles, the exploit is patched in newer firmware and you need to keep the system outdated to trigger it and access homebrew. the emuNAND (or redirected NAND access) is used as a way to still have an updated copy of the system that you use online.

On switch, that's the contrary. if your switch has the RCM bug, it can't be patched and therefore you can update the console and use it online with OFW without problem.
the emuMMC/redirectedMMC access is used now for homebrew and mods. that copy is to be kept offline forever (or you'll get your system banned ! emuMMC doesn't prevent ban ! be careful)

SysMMC : online, updated OFW, no AutoRCM, dedicated SD card.
emuMMC : offline, homebrew, mods, games, jig required to boot it, dedicated SD card!

The only fear I have is if emuMMC reboots itself due to error, then it would boot the OFW with the wrong SD card inserted, no autoRCM to stop booting by mistake. if nintendo added a SD content or emu partition detection, you'll mess your OFW with it.

ScarletDreamz · Jun 19, 2019

Cyan said:
you used linux or windows? which command did you type?

yes, that's why emuMMC on switch is to be used differently than how users are used to with other consoles.
on most consoles, the exploit is patched in newer firmware and you need to keep the system outdated to trigger it and access homebrew. the emuNAND (or redirected NAND access) is used as a way to still have an updated copy of the system that you use online.

On switch, that's the contrary. if your switch has the RCM bug, it can't be patched and therefore you can update the console and use it online with OFW without problem.
the emuMMC/redirectedMMC access is used now for homebrew and mods. that copy is to be kept offline forever (or you'll get your system banned ! emuMMC doesn't prevent ban ! be careful)

SysMMC : online, updated OFW, no AutoRCM, dedicated SD card.
emuMMC : offline, homebrew, mods, games, jig required to boot it, dedicated SD card!

The only fear I have is if emuMMC reboots itself due to error, then it would boot the OFW with the wrong SD card inserted, no autoRCM to stop booting by mistake. if nintendo added a SD content or emu partition detection, you'll mess your OFW with it.

Yeah. thats the issue i was having understanding the differences with it, thanks for taking your time explaining it.

Now, so far users that decide to do this would lose the change of a warmboot exploit since it was patched after 7.0.1, that would be the biggest lost, so to speak.

Cyan · Jun 19, 2019

yes, that's right.
you lose that if you want to go online and use a clean system, with burned efuse. you'll need a jig and no autorcm.
too bad there's no payload to actually boot Horizon officially from RCM since 7.x. That would prevent the need to use jig (you'll have burned fuse, but it's not a problem for cfws launched from emu partition)

ScarletDreamz · Jun 19, 2019

Cyan said:
yes, that's right.
you lose that if you want to go online and use a clean system, with burned efuse. you'll need a jig and no autorcm.
too bad there's no payload to actually boot Horizon officially from RCM since 7.x. That would prevent the need to use jig (you'll have burned fuse, but it's not a problem for cfws launched from emu partition)

What about using hekate to boot to stock using autorcm? to avoid burning fuses? update using choidujournx to 8.1.0, if I'm willing to risk my nand for it, would probably be:

Update using choirdojournx to 8.1.0
Try to clean nand, [people state that is impossible, im willing to risk it]
and use hekate to boot to 8.1.0 stock, my biggest question would be, does booting stock from hekate create or sends something to telemetry?

shado9573 · Jun 19, 2019

Is it still using hidden partition or will EmuMMC files be visible on the SD card?

RHOPKINS13 · Jun 19, 2019

Cyan said:
- create a FAT32 near the end and write emuMMC before FAT32 but without creating a partition info on the MBR,
- create multiple FAT32, but then delete the partition where you installed emuMMC so it is not marked as FAT32 anymore!

Don't these two options pretty much result in the same thing? (emuMMC at the beginning of the SD card, not listed in a partition in MBR, followed by a FAT32 partition to the end of the drive).

I'd be interested in how you would write this in a guide. If I take my "emunand.bin" file and dd it straight to the SD card without a partition (/dev/sdb vs /dev/sdb1) how would I go about making a FAT32 partition and ensuring that neither the MBR nor the FAT32 partition overlapped the data I just wrote with dd? I'd love a tutorial on this method using Linux commands!

Bl4ckeagle · Jun 19, 2019

Can be deleted!

RyanfromWork · Jun 19, 2019

Background:

My clean OFW back up is from 4.0.1 FAT32. I have updated to 6.0.1 but never went online, i have 7 burnt fuses. (It is obvious why i have 7 burnt)

at this point, i have successfully downgraded to 4.0.1 using my backups, but of course i can’t load into Horizon due to fuses. I can check what FW i have via loading into CFW. it shows 4.0.1 (AMS 0.9.0).

Prior to using this guide was the other guide that uses sxos. But the same problem, will only load into my clean backup. (I hope its “clean” still)

Issue:
Since then and before the geniuses who released 0.9.0, I have upgraded to 7.0.1 via method not burning fuses.

Following this guide to the “T”. I have made my boot0+boot1+rawnand.bin (7.0.1) to my emuMMC file for the hidden partition.
I loaded that into the hidden partition via DD (i left 32 gigs at the “end part” as instructed)

I cannot get the switch to load into the emuMMC. (Which i am assuming is 7.0.1). (Oh hell yes of course i redid the entire process using several different cards.)

Before i thrown in the towel, can anyone give me a hint or clue as to why I cannot get my switch to load the hidden partition??

It will only load into 4.0.1 (ams 0.9.0). I know due to 7 fuses being burnt, that AMS is bypasssing the fuse count check. So i am in CFW, but not the desired one.

Is there something i am missing??

Xw2X · Jun 19, 2019

Does this mean we can go online with emmuNAND like the 3DS?

Bl4ckeagle · Jun 19, 2019

Xw2X said:
Does this mean we can go online with emmuNAND like the 3DS?

No only with "stock" and bought games!
With Emunand you can play the other games in flightmode.

RyanfromWork · Jun 19, 2019

Bl4ckeagle said:
Sorry for the stupid question how do I know if I'm on the emummc and when in stock?

I assume you would go look at the FW you are on, and if it has (ams 0.x.x) next to your FW, you have to be in CFW.

I am using (ams 0.x.x) as that is all i am used to. If youre running stock, or HOS, you wont see ams. Unless you are using Hetake and choosing to loading “stock FW”

I hope I’m not giving you false info.... but i am telling you out of my experience.

Bl4ckeagle · Jun 19, 2019

AMS just stands for Atmosphere, which means you are in AMS.
Doesnt matter if EmuNand or NAND

Has an itch needing to be scratched.

GBATemp's lurking knight

Well-Known Member

~Zexceil

GBATemp's lurking knight

~Zexceil

[Debug Mode]

New Member

GBATemp's lurking knight

[Debug Mode]

GBATemp's lurking knight

[Debug Mode]

Well-Known Member

Geek

Active Member

Member

Member

Active Member

Member

Active Member

Similar threads

Popular threads in this forum