* Goodies:

- EmuTool: https://github.com/TheyKilledKenny/Emutool/releases
- Minitool Partition Wizard ( free ): https://cdn2.minitool.com/?p=pw&e=pw-free

* Optional goodies ( if you have emunand 11.0.1, to hybridize it for SX OS, steps 0 and 7 ):

- lockpick_RCM payload to obtain your prod.keys: https://github.com/shchmue/Lockpick_RCM/releases
- NxNandManager: https://github.com/eliboa/NxNandManager/releases ( I used the x64 version )
- BCPKG2 package: < removed link, please go to sthetix's twitter account and use the link there >


* The steps I do to convert an atmosphere style microsd to an SXOS style microsd are:

optional 0) If your emunand is 11.0.1, you need to hybridize it with replacement bcpkg2 and for that you need your prod.keys file:
- use lockpick_RCM.bin and dump keys from emunand. These are stored in sdcard:/switch/prod.keys. You can grab this and save it elsewhere, but you can use it from that location directly too.

1) Use Emutool to save the atmosphere hidden partition to an atmosphere file.

2) Use Minitool Partition Wizard ( free ) to:
- delete the hidden emunand partition and apply changes.
- move the FAT32 ( if you use exFAT you are out of luck and you will need to do the long way, copy contents, format as FAT32 and copy back, or maybe use another tool that can convert or move esFAT ) partition to the very end of the physical space. Take care to leave 29.22 GB ( or a bit more, it won't hurt ) of free space on the beginning of the physical space. And apply changes. This took a bit more than half an hour for a 400GB sdcard that was almost full, way less than doing it the long way by copying contents and restoring them and all that.

3) Use Emutool to restore the atmosphere file to the microsd as SXOS hidden partition.

4) Move the Nintendo folder found in sdcard:/emuMMC/RAW1/ to sdcard:/, that is, you have sdcard:/emuMMC/RAW1/Nintendo and you must end up having sdcard:/Nintendo

5) Rename sdcard:/Nintendo to sdcard:/Emutendo

6) Use Emutool, select sxos hidden partition emu as source and click on Activate emu button that appears below. This is needed for SXOS to detect and use the hidden emunand partition. ( Thank you @TheyKilledKenny ! ).

optional 7) if your emunand is 11.0.1, you need to hybridize it with replacement bcpkg2 by replacing the 4 partitions on the sxos style emunand:
- start NxNandManager and go to Options>Configure keyset and click Import keys from file and select the prod.keys file obtained in step 0 ( from sdcard:/switch/ or from wherever you saved it ). Make sure the key slots are filled in and clicked Save
- go to File>Open drive and select the microsd drive.
- click on BCPKG2-1-Normal-Main in Partitions pane and click on backup file icon to back it up
- click on BCPKG2-2-Normal-Sub in Partitions pane and clicked on backup file icon to back it up
- click on BCPKG2-3-SafeMode-Main in Partitions pane and clicked on backup file icon to back it up
- click on BCPKG2-4-SafeMode-Sub in Partitions pane and clicked on backup file icon to back it up
- click again on BCPKG2-1-Normal-Main in Partitions pane and click on restore file icon and select the equally named file from the package sthetix linked on his twitter and confirm
- click again on BCPKG2-2-Normal-Sub in Partitions pane and click on restore file icon and select the equally named file from the package sthetix linked on his twitter and confirm
- click again on BCPKG2-3-SafeMode-Main in Partitions pane and click on restore file icon and select the equally named file from the package sthetix linked on his twitter and confirm
- click again on BCPKG2-4-SafeMode-Sub in Partitions pane and click on restore file icon and select the equally named file from the package sthetix linked on his twitter and confirm


EDIT: Needless to remind you that making this SXOS style microsd and emunand compatible with atmosphere is quite easy, look it up here on GBATemp or elsewhere. Also, I'd recommend ending up with such a combo, so you can then easily use both OSes almost without changing the microsd layout.
Good luck

 

[DbGt]

Hmmm, that resized emunand thing is tempting me a couple of GB should suffice... what's the minimum size we can use ?

Also, thank you for the info on that app, will it work on mariko switches ? I will try

About the last part, yes, I click on the unallocated space that's left to the right, the ending physical part, and see its properties and note the starting physical sector, which is a decimal number. Then I convert it to hexadecimal and put it in the sector box in EmuTool in restore to atmosphete partition. This will write to the microSD starting at that sector and will also make changes to emummc.ini; you can open it and see/confirm the same number you put in that box is set.

EDIT: How do you do those shrinked emunands ? ( me has puesto los dientes largos, quiero quiero )

mmm i dont know, i think Mariko cannot use reboot-to-payload, which this app is based on, but im not sure as i dont have a mariko unit.

As for whats the minimum size, the minimum partition size that can be made with hekate is 4gb, take into account that the switch os takes about 2.7gb, so in that case you will have about 1.3 gb free, which i think is not that much for saves, i think 2gb should be the minimum, 3gb would be ideal, at least in my case. To have at least 3gb for saves you need a 6gb nand. If you dont use hekate, and just use nx nandmanager then you could play a lot more with the numbers as it allows you to exactly specify what size you want.

Well, first of all i did a 29gb sd partition and a full sized emunand, both of this with hekate, this is so I can have a 1:1 copy of my sysnand (I used CFW in sys before), then I boot it up, then i removed all saves with JKSV (user, device and BCAT saves) and deleted all games with "untitled" app, this is to conserve only the switch profiles but you could also simply do a console initialisation and erase everything. After this I did an emunand backup with either nxnandmanager (connected through hekate) or with hekate itself.

Then I opened this backup (with everything deleted, except the profiles) with nx nandmanager and resized the "USER" to 3470mb for a total nand size of 6.1gb (I chose this number cause hekate can only do partitions with increments of 1 gb, so this USER size is the closest in total nand size as a hekate 6gb partition). Then in hekate I did an SD partition of 6gb, after this i created an emummc in this resized partition also in hekate.

Then I restored my resized 6gb nand (that had everything deleted except profiles) that i made with nx nandmanager. To do this I connected the emummc raw GPP of the 6gb emunand i had just created with hekate to nx nandmanager through hekate sd tools. As the sizes from the resized 6gb nand made before (the "clean" one) and the 6gb nand created with hekate are not identical, I had to restore it manually with a left click in each part in nx nand manager; user, system, safe, etc etc, selecting "restore from file" and selecting my clean resized 6gb nand each time. After doing this, and now having my "clean" resized nand restored in the hekate partition, I did a backup of this nand with nx nandmanager to have a 6gb clean nand backup with the exact size of a 6gb hekate partition, so it could be much easier and quicker to restore in the future if necessary.

After this, I did exactly the same steps all over again, the only difference was that this time instead of deleting all games, I archived them so that their icons could still be visible and I could see which games I had played, the games are still deleted when you archive them but the icons are not removed, thats the only difference, I also deleted the saves with JKSV as the first time.

Then with emutools i did a conversion of hidden atmos partition emu to sx file emu.

So now I have 2 clean 6gb nands backups with the exact hekate partition size, one with everything deleted except profiles (this is for my atmos emu, as everything there will be new), the other one with everything deleted except profiles and played game icons (this one is for my sx emu, as i have played everything till date with that cfw).

Finally i just restored my clean atmos 6gb nand backup to the 6gb partition that was created with hekate using nx nand manager by selecting full/partial restore (this step could be avoided if i had begun with the "sx emu"), then with minitool partition wizard i moved the FAT32 partition so that it begins at 6.1gb, then with emutools i converted the sx file emu to sx hidden partition emu, loaded the sx hidden partition emu and activated it with emutools.

So thats it, why didnt I just used a resized emunand made directly with hekate? well cause i wanted it to be as clean as possible, thats why i first made a full sized emu and cleaned it myself before resizing it. Also because for some reason theres more free space in the end doing it this way than just resizing it directly with hekate.

Why i deleted all saves, games (or archived them)? Cause when you resize a nand, the USER part will be formatted and even if there are no games or saves anymore, you will have to delete them manually, no game will launch otherwise, an error will occur if you do not do this. So I did this step before resizing the nand.

EDIT: In the end I initialized both of my 6gb emunands because for some reason I was having errors when launching some games, dont know exactly what was the problem... so all the steps i did to conserve my user profiles could have been avoided.... Its easier to just do a 6gb partition with hekate, when create en emummc with hekate, then boot it up, initialize it, then do a backup of this emummc with nxnandmanager, and also transform the emummc to sx os file emunand with emutools, then with minipartition tool wizard resize your main partition to allow 6gb of unallocated space at the start of the sd, then with emutools convert the sx os files emunand to sx hidden partition emunand.

 

[wurstpistole]

Why exactly would you want to do that?
SX is dead, the other way around would make much, much more sense

 

[lordelan]

...

Nice guide, thx. Since you're into the topic as it seems, try to find a way to use an SX OS emuNAND on the same SD card as Android 10 and you can become the hero of a whole generation.

 

[Inaki]

Nice guide, thx. Since you're into the topic as it seems, try to find a way to use an SX OS emuNAND on the same SD card as Android 10 and you can become the hero of a whole generation.

Heroes of the generation are all those hekate, atmosphere, ... tools, etc. developers, those are the ones

Now, what is the problem with that android 10 and sxos ? is it android the one that fails to boot ? if the unallocated space ( that is, not described by a partition ) with sxos emunand is at the beginning of the physical space on the microSD card, sxos will detect and use it ( it needs the TX NAND mark in sector 1, just before the emunand contents that start at sector 2, of course ). Is it android 10 the one that doesn't boot ? Or is it some tool giving problems when creating the partition ?

I do have a 1st generation switch with SX Pro dongle soldered inside it, but I lent it to a friend... I may need to swap it for a mariko one I have and so I can try...

Please give some info/context... thank you.

 

[lordelan]

Heroes of the generation are all those hekate, atmosphere, ... tools, etc. developers, those are the ones

Now, what is the problem with that android 10 and sxos ? is it android the one that fails to boot ? if the unallocated space ( that is, not described by a partition ) with sxos emunand is at the beginning of the physical space on the microSD card, sxos will detect and use it ( it needs the TX NAND mark in sector 1, just before the emunand contents that start at sector 2, of course ). Is it android 10 the one that doesn't boot ? Or is it some tool giving problems when creating the partition ?

I do have a 1st generation switch with SX Pro dongle soldered inside it, but I lent it to a friend... I may need to swap it for a mariko one I have and so I can try...

Please give some info/context... thank you.

Did not expect that you take that seriously since it's very hard to achieve if not impossible, but I'll gladly tell you, what the main problem is:
The SX OS emuNAND starts at the first sector (as you already know) and requires the micro SD card to be in MBR while Android requires GPT. That's the main issue. We would need some kind of MBR/GPT hybrid solution and probably some hex editing to get that running but I'm not skilled enough to achieve that.
The only fallback solution would be to use a filebased emuNAND instead since it's gotten already as fast meanwhile. That way it would be inside the regular FAT32 partition of Horizon that is present nonetheless on Android setups. However, the problem here is that the filebased emuNANDS are different between SX OS and Atmosphère/hekate so you can't create one and dual boot between both custom firmwares like you can with a partition based emuNAND.

 

[Inaki]

Did not expect that you take that seriously since it's very hard to achieve if not impossible, but I'll gladly tell you, what the main problem is:
The SX OS emuNAND starts at the first sector (as you already know) and requires the micro SD card to be in MBR while Android requires GPT. That's the main issue. We would need some kind of MBR/GPT hybrid solution and probably some hex editing to get that running but I'm not skilled enough to achieve that.
The only fallback solution would be to use a filebased emuNAND instead since it's gotten already as fast meanwhile. That way it would be inside the regular FAT32 partition of Horizon that is present nonetheless on Android setups. However, the problem here is that the filebased emuNANDS are different between SX OS and Atmosphère/hekate so you can't create one and dual boot between both custom firmwares like you can with a partition based emuNAND.

Yes, I thought about modifying boot.dat so that it detects the emunand in the new partition scheme...

But, anyway, I've got an idea
What if...
- We create a hekate+atmosphere emummc.ini to use a hidden partition style emunand.
- We create an SXOS file based style emunand STRUCTURE and arrange file data in the FAT32 partition so that the file entries are describing data for each file, yes, as it would be the case for a file based SXOS emunand, BUT we also make sure that data is contiguos on disk:

sd:/emummc/emummc.ini contents:

[emummc]
enabled = 1
sector = <sector where BOOT0 - and the contiguous files - data starts NANDSTART*>
nintendo_path = Emutendo

File view at sd:/sxos/emunand/

BOOT0
BOOT1
<FULL NAND whatever 00>
<FULL NAND whatever 01>
<FULL NAND whatever 02>
<FULL NAND whatever ...>

Physical View
NANDSTART*> [BOOT0][BOOT1][FN 00][FN 01][FN 02][FN ...]

To create this more or less easily, we would just write a FULLNAND.bin ( with all the nand contents ) file to the FAT32 partition and defragment it. It would be advisable to start with an empty/newly formatted FAT32 partition and just write a full content file there so it is contiguos on disk. I don't know for sure but I think it will be sector aligned by default, otherwise we would need to prepend the written file with 512 dummy bytes first... long story, but this would let us move the contents to align to 512 byte later. The last part is manually editing FAT32 filesystem file entries so that the individual files point to the correct sectors, not that easy but not that difficult either.

Two things:
1) We would just need to be carefull when mounting the SD on PC for it not to try to fix the FAT32 file table, etc. I assume this is not done atomatically, not in the PC OS nor in Horizon OS. Also, since the trick is "self contained", there should be no problem of "off place data overwriting" or anything. Of course, the FULLNAND.bin file would still have to be left there so that the file contents are preserved and nothing overwrites the contents space and so on.

2) Now, I need to know this, do SXOS with file style emunand and android 10 work together ? Forget about atmosphere by now, does that work ? if that works, there's some ( big ? ) chance of success, even without SXOS modifications.


LAST EDIT: I tried with two different microSD cards ( not a sandisk one though ) formatted as GPT and just with boot.dat and license.dat and I always get the sad microsd card logo. Does SX OS even support GPT formatted microSD cards ? If it doesn't support that, then all this idea is useless, the problem wouldn't be to be able to use atmosphere+sxos+switchroot(android/linux) but to use SXOS with a GPT mode micrSD card... :\

So, I reread your comment and noticed we would need BOTH, giving boot.dat support for GPT partitioning or maybe doing some strange hybrid of GPT and MBR ( found this: https://www.rodsbooks.com/gdisk/hybrid.html but I don't know if switchroot would support such a thing and then if SXOS would support it also... ) AND this mixing of emunand descriptions, which I still believe is actually doable. I'll have a look if there's a way to have and MBR/GPT mix or something like that. Otherwise, modng boot.dat is actually possible, more so on Erista consoles ( on RCM ones / unpatched ones at least ), you know from the Hack SX OS thread that Reacher17 and mrdude have been doing this for a while. And once you start modding that we may as well do the "rebasing" of the first sector there too...

Now, this needs a bit of crafting and it may still be not possible ( although I think it should work, difficult to explain why, basically because we are talking big -4MB for boot0 and boot1 is "big" too, in this sense- files and alignable/multiplo sized ones... ).

EDIT: The good part is I can try this on a mariko switch, even if I don't actually install android to it. If that 2) is so, if SXOS with file based emunand and android do work together, then we can probably get this working...

EDIT2: I am thinking about it and we may need to align the FULLNAND.bin to 32KB ( and probably prepend it with that same amount so that we can ensure that alignment later ) because how FAT32 works ( not sure but this is an educated guess ) and how it addresses sectors on disk... EDIT: probably not needed.

EDIT3: That FULLNAND.bin would actually be 1, 2,... 8 files instead of just one, for FAT32 at least, for obvious reasons. And we would need to ensure the files are contiguos on disk, a bit trickier, but still "easy". There may even be a way to obtain this without manually editing FAT32 file entries ( like, starting with an empty / formatted FAT32 partition, write BOOT0, then write BOOT1, then write FN 00, then... so that the contents may just get written contiguously ).

 

[lordelan]

Yes, I thought about modifying boot.dat so that it detects the emunand in the new partition scheme...

But, anyway, I've got an idea
What if...
- We create a hekate+atmosphere emummc.ini to use a hidden partition style emunand.
- We create an SXOS file based style emunand STRUCTURE and arrange file data in the FAT32 partition so that the file entries are describing data for each file, yes, as it would be the case for a file based SXOS emunand, BUT we also make sure that data is contiguos on disk:

sd:/emummc/emummc.ini contents:

[emummc]
enabled = 1
sector = <sector where BOOT0 - and the contiguous files - data starts NANDSTART*>
nintendo_path = Emutendo

File view at sd:/sxos/emunand/

BOOT0
BOOT1
<FULL NAND whatever 00>
<FULL NAND whatever 01>
<FULL NAND whatever 02>
<FULL NAND whatever ...>

Physical View
NANDSTART*> [BOOT0][BOOT1][FN 00][FN 01][FN 02][FN ...]

To create this more or less easily, we would just write a FULLNAND.bin ( with all the nand contents ) file to the FAT32 partition and defragment it. It would be advisable to start with an empty/newly formatted FAT32 partition and just write a full content file there so it is contiguos on disk. I don't know for sure but I think it will be sector aligned by default, otherwise we would need to prepend the written file with 512 dummy bytes first... long story, but this would let us move the contents to align to 512 byte later. The last part is manually editing FAT32 filesystem file entries so that the individual files point to the correct sectors, not that easy but not that difficult either.

Two things:
1) We would just need to be carefull when mounting the SD on PC for it not to try to fix the FAT32 file table, etc. I assume this is not done atomatically, not in the PC OS nor in Horizon OS. Also, since the trick is "self contained", there should be no problem of "off place data overwriting" or anything. Of course, the FULLNAND.bin file would still have to be left there so that the file contents are preserved and nothing overwrites the contents space and so on.

2) Now, I need to know this, do SXOS with file style emunand and android 10 work together ? Forget about atmosphere by now, does that work ? if that works, there's some ( big ? ) chance of success, even without SXOS modifications.


LAST EDIT: I tried with two different microSD cards ( not a sandisk one though ) formatted as GPT and just with boot.dat and license.dat and I always get the sad microsd card logo. Does SX OS even support GPT formatted microSD cards ? If it doesn't support that, then all this idea is useless, the problem wouldn't be to be able to use atmosphere+sxos+switchroot(android/linux) but to use SXOS with a GPT mode micrSD card... :\

So, I reread your comment and noticed we would need BOTH, giving boot.dat support for GPT partitioning or maybe doing some strange hybrid of GPT and MBR ( found this: https://www.rodsbooks.com/gdisk/hybrid.html but I don't know if switchroot would support such a thing and then if SXOS would support it also... ) AND this mixing of emunand descriptions, which I still believe is actually doable. I'll have a look if there's a way to have and MBR/GPT mix or something like that. Otherwise, modng boot.dat is actually possible, more so on Erista consoles ( on RCM ones / unpatched ones at least ), you know from the Hack SX OS thread that Reacher17 and mrdude have been doing this for a while. And once you start modding that we may as well do the "rebasing" of the first sector there too...

Now, this needs a bit of crafting and it may still be not possible ( although I think it should work, difficult to explain why, basically because we are talking big -4MB for boot0 and boot1 is "big" too, in this sense- files and alignable/multiplo sized ones... ).

EDIT: The good part is I can try this on a mariko switch, even if I don't actually install android to it. If that 2) is so, if SXOS with file based emunand and android do work together, then we can probably get this working...

EDIT2: I am thinking about it and we may need to align the FULLNAND.bin to 32KB ( and probably prepend it with that same amount so that we can ensure that alignment later ) because how FAT32 works ( not sure but this is an educated guess ) and how it addresses sectors on disk... EDIT: probably not needed.

EDIT3: That FULLNAND.bin would actually be 1, 2,... 8 files instead of just one, for FAT32 at least, for obvious reasons. And we would need to ensure the files are contiguos on disk, a bit trickier, but still "easy". There may even be a way to obtain this without manually editing FAT32 file entries ( like, starting with an empty / formatted FAT32 partition, write BOOT0, then write BOOT1, then write FN 00, then... so that the contents may just get written contiguously ).

Well ... that's some effort here. Nice!
Not sure if I understood more than half of all the things you wrote but those I understood are giving me some hope at least.
Either a hybrid has to work with both (SX OS and Android) or boot.dat can be altered as much so that SX OS (finally) supports GPT.
Can't answer your questions as I didn't test those (interesting) ideas yet, but ...
maybe you're really in a spot to become the hero of a whole generation.

 

[Inaki]

Well ... that's some effort here. Nice!
Not sure if I understood more than half of all the things you wrote but those I understood are giving me some hope at least.
Either a hybrid has to work with both (SX OS and Android) or boot.dat can be altered as much so that SX OS (finally) supports GPT.
Can't answer your questions as I didn't test those (interesting) ideas yet, but ...
maybe you're really in a spot to become the hero of a whole generation.

I am trying to manually edit first sector to put a valid MBR there. GPT definitions start at sector 1, so let's see if I can force a hybrid ( actually more than a hybrid ). The "good" part is we can always relax switchroot boot manager code to use the GPT part and force it to ignore the MBR part and so on, we have the code for that, right ? I have both MBR and GPT describe the same FAT32 partition, same start, same size, so for SXOS it would work as is... provided that it doesn't check something else besides sector 0, MBR, partitions, etc. ( we know sector 1 needs an specific mark for SXOS hidden emunand partition detection, but we don't need that in this case, we are trying to use SXOS file based emunand so... )
We shall see.

P.S.: I'll explain myself better if this leads to something...

 

[lordelan]

Amazing. You're getting me a little hyped to be honest.

The "good" part is we can always relax switchroot boot manager code to use the GPT part and force it to ignore the MBR part and so on, we have the code for that, right ?

Is that so? Didn't know.
But I wonder if we would still be able to access the Horizon FAT32 partition from within Android then.
At least this would be important to me to continue RetroArch savegames from either Horizon or Android whenever I booted into one of the two.

 

[Inaki]

Amazing. You're getting me a little hyped to be honest.

Is that so? Didn't know.
But I wonder if we would still be able to access the Horizon FAT32 partition from within Android then.
At least this would be important to me to continue RetroArch savegames from either Horizon or Android whenever I booted into one of the two.

Yes, switchroot is open source software. Here is the TWRP code that deals with GPT:

https://gitlab.com/switchroot/android/android_bootable_recovery/-/blob/android-9.0/gpt/gpt.c

function find_valid_gpt is where we may need to change some checks so it ignores MBR ( from a quick read it seems it may already do so itself but not sure ).

I am still trying. I am not using a hybrid GPT, I am just describing the same FAT32 partition in MBR ( sector 0 ) and GPT ( sector 1 and on ) and I already booted sxos ( nothing new here, expected ).

As for seeing the FAT32 partition from Android, the same principle applies, but instead of in the TWRP we would need to do MBR sector ignoring changes in the Android subbranch ( which may ignore it itself already or may have an option to force GPT ).

I will be getting my unpatched Erista switch I lent to a friend back today and I will continue with the trickery...

 

[lordelan]

Yes, switchroot is open source software. Here is the TWRP code that deals with GPT:

https://gitlab.com/switchroot/android/android_bootable_recovery/-/blob/android-9.0/gpt/gpt.c

function find_valid_gpt is where we may need to change some checks so it ignores MBR ( from a quick read it seems it may already do so itself but not sure ).

I am still trying. I am not using a hybrid GPT, I am just describing the same FAT32 partition in MBR ( sector 0 ) and GPT ( sector 1 and on ) and I already booted sxos ( nothing new here, expected ).

As for seeing the FAT32 partition from Android, the same principle applies, but instead of in the TWRP we would need to do MBR sector ignoring changes in the Android subbranch ( which may ignore it itself already or may have an option to force GPT ).

I will be getting my unpatched Erista switch I lent to a friend back today and I will continue with the trickery...

Amazing. You already went deeper into this than anyone else before. Fingers are crossed!

 

[dcx6723]

I didn't read.

 

[Inaki]

I didn't read.

Reading is good, it lowers you anxiety, for example.

P.S.: Just got my unpatched Erista switch back, looking into the partition scheme and all that... ( this switch already has android 10 installed ).

 

[Inaki]

Amazing. You already went deeper into this than anyone else before. Fingers are crossed!

Got it working

- We have atmosphere and sxos using the same emunand and android 10 seeing the FAT32 partition.

- It is also easier than expected due to:

a) sxos already generating physically contiguous files when creating emunand ( NOTE: this is empirically so, it could be that this is not always the case but my intuition or educated guess tells me TX did this so for their convenience, so we should be fine; also, this could be fixed manually or with a program when and if it happens to not be the case; the good thing is that, once you create a file based emunand with sx os and it happens to be contiguos, you don't need to worry anymore ).

b) hekate ( nyx ) already generating the required hybrid MBR partition layout.

- atmosphere is using the emunand as a hidden partition as if it was using an sxos hidden partition style emunand

- sxos is using the emunand as an sxos file based style emunand

- android 10 needs to be rooted with magisk and you need to enable global namespace on magisk

- you can then access the FAT32 partition with an app that supports root and raw file namespace to access /mnt/... and so on or you can use a script to mount it or tasker to automount it on boot ( there's a thread for this automounting thing on xda-developers ). I personally use x-plore and just access it directly.

Now, I may do a demonstration video and upload to youtube or some other place. Also, I have to see how to explain how to get this working as easy as posible.

 

[lordelan]

Got it working

- We have atmosphere and sxos using the same emunand and android 10 seeing the FAT32 partition.

- It is also easier than expected due to:

a) sxos already generating physically contiguous files when creating emunand ( NOTE: this is empirically so, it could be that this is not always the case but my intuition or educated guess tells me TX did this so for their convenience, so we should be fine; also, this could be fixed manually or with a program when and if it happens to not be the case; the good thing is that, once you create a file based emunand with sx os and it happens to be contiguos, you don't need to worry anymore ).

b) hekate ( nyx ) already generating the required hybrid MBR partition layout.

- atmosphere is using the emunand as a hidden partition as if it was using an sxos hidden partition style emunand

- sxos is using the emunand as an sxos file based style emunand

- android 10 needs to be rooted with magisk and you need to enable global namespace on magisk

- you can then access the FAT32 partition with an app that supports root and raw file namespace to access /mnt/... and so on or you can use a script to mount it or tasker to automount it on boot ( there's a thread for this automounting thing on xda-developers ). I personally use x-plore and just access it directly.

Now, I may do a demonstration video and upload to youtube or some other place. Also, I have to see how to explain how to get this working as easy as posible.

Are you f*cking serious?!
You managed to do it? Wow, I'm really speechless!
Yes, please do a video and then a step by step guide! =)
Can't wait!
I'll be getting a 512 GB card then to do this.
Also I'll be telling all my friends who wanted this too and then you're officially a hero of a whole generation.

 

[Inaki]

Are you f*cking serious?!
You managed to do it? Wow, I'm really speechless!
Yes, please do a video and then a step by step guide! =)
Can't wait!
I'll be getting a 512 GB card then to do this.
Also I'll be telling all my friends who wanted this too and then you're officially a hero of a whole generation.

I am serious. But please, let's not blow this out of proportion, this is not that big of a thing

Recording a proof video now...

 

[lordelan]

I am serious. But please, let's not blow this out of proportions, this is not that big of a thing

Recording a proof video now...

Appearently I can tell you it is!
Few skilled people already tried this and got nowhere.

 

[Inaki]

Having dinner, I'll be doing a guide with drawn screenshots after I finish my tenderloin and wine

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

Having dinner, I'll be doing a guide with drawn screenshots after I finish my tenderloin and wine

And remember:

 

[Inaki]

This is a video I recorded and I am not very proud of ( I lost an awful lot of my and your time trying to download some NSP files to do some tests and I wanted the video to be an unedited all-in-one-shot video por proof sake, so... ), but you can watch first 15 minutes and then either that's it or skip to minute 32 or so. Last 5 minutes or so explain the essence of the trick.



Going for the guide now.

 

[lordelan]

This is a video I recorded and I am not very proud of ( I lost an awful lot of my and your time trying to download some NSP files to do some tests and I wanted the video to be an unedited all-in-one-shot video por proof sake, so... ), but you can watch first 15 minutes and then either that's it or skip to minute 32 or so. Last 5 minutes or so explain the essence of the trick.



Going for the guide now.

Completely fine with that video. Thanks a lot (again). It shows how great your achievement is!