As the title says, here's the video; I'll do a write up later since it's a long process.



This is not possible in windows 10 due to the GPT Hybrid MBR trickery used, the android image already does this when it writes the partition tables and etc.

Don't do this in windows nor attempt it, it's not going to happen unless there's something you can use to mess with partitions like I did, L4T-Ubuntu also won't work due to the partition stuff and etc, I'm currently making something to allow this without any complications, please be patient!

Watch the entire video and you'll understand more about this, if you make simple errors from not watching the video I will simply tell you to properly watch again and listen!
TOOL ETA: Don't ask, it's a complicated tool that needs a lot of maths, safety features and etc
TOOL SO FAR:

Tool functions: Android, Custom Android user data, 8GB Android install, Ubuntu, Ubuntu Swap, EmuMMC and Lakka dynamic setup.
Planned functions: Multi EmuMMC setup, EmuMMC Backup & restore(including Nintendo folder) + More unique management stuff!

UPDATE: I'm currently setting aside the tool until I finish making & releasing my new modchip

 

[TariqSoftDev]

Hi i have a 400 GB sd card where i have my emunand in files not a hidden partion. I only have a Windows machine. Can i backup everything and make a android partion on 32gb and some how expand the fat32 partion so i can boot both on the same card on windows.

You need Linux, says it in the thread; Windows can't make Hybrid MBRs

 

[stoffer666]

You need Linux, says it in the thread; Windows can't make Hybrid MBRs

Thought so thx for the answer anyway

 

[TariqSoftDev]

This guide is really amazing. Gladly you worked it out @TariqSoftDev
Only sad thing is that it doesn't support SX OS emuNAND as I created mine from there (and am using SX OS to launch games from HDD from time to time).

Can be done with SX OS, just need to do it right when it comes to hyrbid MBR trickery and etc; I don't have a SX OS License so I'm not really going to make a video on it anytime soon.

 

[lordelan]

Can be done with SX OS, just need to do it right when it comes to hyrbid MBR trickery and etc; I don't have a SX OS License so I'm not really going to make a video on it anytime soon.

You don't need a SX OS licence for that at all. You can just download their CFW for free, create the emuNAND for free and boot into it without paying. You just can't use their sigpatches and rommenu from within the booted CFW.

 

[jan2705]

This guide is really amazing. Gladly you worked it out @TariqSoftDev
Only sad thing is that it doesn't support SX OS emuNAND as I created mine from there (and am using SX OS to launch games from HDD from time to time).

file-based emunand seem to work petty well with sx-os even on fat32, but i didn't tried alongside this guide yet

 

[lordelan]

file-based emunand seem to work petty well with sx-os even on fat32, but i didn't tried alongside this guide yet

Yeah but file based is pretty slow in Atmosphère.

 

[jan2705]

Yeah but file based is pretty slow in Atmosphère.

yes on atmosphere use partitioned emummc for now,but on sxos at least playing xci's works pretty well on fat32/file-based

 

[lordelan]

yes on atmosphere use partitioned emummc for now,but on sxos at least playing xci's works pretty well on fat32/file-based

Sure but since the emuMMC is the only place for me to use CFW (sysNAND stays clean) I obviously want to use it with both custom firmwares (Atmo and SX OS) to benefit from both.
SX OS has the HDD XCI loading (only thing I need there though) while Atmo has all the fantastic sysmodules and is just the better CFW(™).
That's why I have to use the partition based emuMMC from SX OS in both CFW while I can't use a one that hekate created (or this guide by Tariq) in SX OS.

 

[Cyan]

sxOS emuMMC needs to be at a specific sector?
if it's hardcoded to be located at sector1, then you can't have both GPT and sxOS emuMMC, as GPT table is on sector1 (and a backup often at MaxSector-63, but rarely known or used by apps)
if it's not hardcoded, or is hardcoded but can be edited in their boot.dat without triggering any brick, that would be nice.

if it's not at sector1, but for example sector 64+ (even sector 4 is far enough), then you might have to start by making the SXOS partition first, then the FAT32.
You'll have to edit all boot.scr to match partition numbers.
You'll also have to NOT include the MMC partition in MBR, or else the switch horizon will try to mount MMC first as fat32. if SXOS requires the MMC partition to be in MBR, put it at second place, like this guide.

 

[lordelan]

sxOS emuMMC needs to be at a specific sector?

Wrote them a mail about this. Usually the answer quickly. We'll see.

 

[Cyan]

you could also check which sector is your MMC created with sxos payload, sector 1 or farer further (thanks!).
but asking them will give an answer whether it's hardcoded or can be edited

 

[lordelan]

but asking them will give an answer whether it's hardcoded or can be edited

Yeah that's what I asked them about. Not at home (where my Switch is) right now, so I can't look up things.

 

[Cyan]

@TariqSoftDev:

I think you made a mistake with the partition's size. some of which you already know.
you are aware about the userdata as you remade it to 8814.9MiB.

note that I use the size from the 16GB sd image, maybe they are different size in the other images, I don't know.
The vendor and system are wrong too, but it's not a big issue as you made them bigger.
Vendor exact size : 1 137 704 448 bytes
You : 1 126.4MiB
Actual: 1 084.9MiB

system exact size : 2 324 692 480 bytes
You: 2 252.8MiB
Actual: 2 216.9MiB


But I think the emuMMC is wrong and can be an issue because you made it smaller.
my MMC dump is 31 268 536 320 bytes
if I add boot0 and boot1 it is : 31 276 924 928 bytes, 29.1GB

you: 29 798.4MiB
actual: 29 828MiB

your MMC partition is smaller than the real MMC size.
it's not an issue if you end your SD card with the MMC, as the raw sectors will be written and read by emuMMC beyond the MBR's last LBA.
but if later you decide to add a new partition at the end (for L4T for example), it'll overwrite it. Or if you create L4T partition before dumping MMC, it'll overwrite L4T header.

I think adding 2 partitions (8GB and 2GB respectively? 7714MiB and 2217MiB exactly) for L4T and swap file can be a good idea for pentaboot.
the boot.scr for partition 9 is provided on first page.

 

[jan2705]

Sure but since the emuMMC is the only place for me to use CFW (sysNAND stays clean) I obviously want to use it with both custom firmwares (Atmo and SX OS) to benefit from both.
SX OS has the HDD XCI loading (only thing I need there though) while Atmo has all the fantastic sysmodules and is just the better CFW(™).
That's why I have to use the partition based emuMMC from SX OS in both CFW while I can't use a one that hekate created (or this guide by Tariq) in SX OS.

my setup atm: clean sysnand(for playing online), ams with raw partition emmummc(for homebrew etc.) & sxos with its own file-based emunand(for xcis) and that works pretty good

with 2 emunands its easier alongside ops setup because the only emummc type which works well with sx/ams at the same time which is sxos-partition-based(afaik) wont go well with ops guide

 

[jan2705]

you could also check which sector is your MMC created with sxos payload, sector 1 or farer further (thanks!).
but asking them will give an answer whether it's hardcoded or can be edited

normally sx-hidden part is writen top sector 0x2

 

[lordelan]

my setup atm: clean sysnand(for playing online), ams with raw partition emmummc(for homebrew etc.) & sxos with its own file-based emunand(for xcis) and that works pretty good

with 2 emunands its easier alongside ops setup because the only emummc type which works well with sx/ams at the same time which is sxos-partition-based(afaik) wont go well with ops guide

Honestly I don't want to deal with two emuNANDs. I'm enjoying the fact that the one I use Atmosphère with is the same (partition based) one I boot into with SX OS to enjoy my HDD games.
If m4xw and the others get to manage the file based one to get a heave speed increase, I just could go for a filebased one (which supports both CFWs as well) but I've been told on the Switchroot Discord that even when the new fs drivers will be finished, the file based hekate/atmo emuMMC will be slow so partition based seem to be the best option to go with.

 

[jan2705]

Honestly I don't want to deal with two emuNANDs. I'm enjoying the fact that the one I use Atmosphère with is the same (partition based) one I boot into with SX OS to enjoy my HDD games.
If m4xw and the others get to manage the file based one to get a heave speed increase, I just could go for a filebased one (which supports both CFWs as well) but I've been told on the Switchroot Discord that even when the new fs drivers will be finished, the file based hekate/atmo emuMMC will be slow so partition based seem to be the best option to go with.

Youre right but -for now- AMS part based wont Work with sxos while SX part based wont Work alongside android

So If u want to use AMS and SX together in the Same emunand Partition u will Need to flash Android to another sdcard

 

[Bst22322]

@TariqSoftDev:

The vendor and system are wrong too, but it's not a big issue as you made them bigger.
Vendor exact size : 1 137 704 448 bytes
You : 1 126.4MiB
Actual: 1 084.9MiB

system exact size : 2 324 692 480 bytes
You: 2 252.8MiB
Actual: 2 216.9MiB

Am I only losing space from having it partitioned like this? No (possible) errors?

@TariqSoftDev:
But I think the emuMMC is wrong and can be an issue because you made it smaller.
my MMC dump is 31 268 536 320 bytes
if I add boot0 and boot1 it is : 31 276 924 928 bytes, 29.1GB

you: 29 798.4MiB
actual: 29 828MiB

your MMC partition is smaller than the real MMC size.
it's not an issue if you end your SD card with the MMC, as the raw sectors will be written and read by emuMMC beyond the MBR's last LBA.

I'm glad I realized this when I was doing it. I made my emummc partition size 29856 MiB

 

[Cyan]

yes, only losing space to make bigger partition definition than the real space used by the file system.
the partition table is mainly used by partition managers and OS to know where the start of the partition is located and where to put next one.
the first sector of that partition then contains the file system info (real usable size, sector number, cluster size, etc.)
it shouldn't create problems if your table has bigger area than actual usable partition's size. but don't quote me, I'm not 100% sure, it all depends how every apps are working and whether they check the size from the table or the file system itself.

 

[Bst22322]

I probably will give it a re format over the coming weekend then. Could you list the correct size for boot, recovery,dtb? Or is
Hos_data (varies)
Vendor 1084.9 MiB (1085 MiB?)
System 2216.9 MiB (2217 MiB?)
Boot 70 MiB
Recovery 70 MiB
Dtb 30 Mib
Userdata (varies)
Emummc 29856 MiB
Correct? Don't quote me on this guys