Tutorial  Updated

Partition based emuMMC and L4T Ubuntu on the same SD card

I take no responsibility for any damage that following this guide might cause to you, your Switch, other devices or your neighbourhood! You have been warned!

With this guide you will create an emuMMC that can be used by KOSMOS/Atmosphère and SX OS. If you don't need/want the latter, you can follow other guides for that but I'm not sure how partitioning is changed then and even if you intend not to use SX OS at all there should be no downside in following this guide as you will end up with an emuMMC that you can use in Atmosphère as well.

Since both processes
  • creating a partition based emuMMC
    and
  • flashing the L4T Ubuntu image to the SD card
are each wiping the whole card, you can't simply do one after the other to achieve this. That's why some more work has to be done.

My way might seem to be a bit laborious but it just worked for me so here's what I did:
  1. Make a full NAND dump with hekate including BOOT0/1 just in case
  2. Since all data will be deleted from your SD card following these steps, create a temp folder on your computer and copy everything into it
  3. Download SX OS boot.dat and put it on the SD card's root directory
  4. Download their payload.bin as well and fire that up on your Switch while it is in RCM and while you hold VOL+
  5. In the SX OS bootmenu click the right button and then emunand
  6. Create a partition based emuNAND from there - this will take some time
  7. After it's finished, put your SD card in your computer. You will have a
    You will end up with the following:
    [30 GB hidden partition][rest of the card formatted to FAT32 with boot.dat on it]
  8. Take a USB flash drive (!) and flash the L4T Ubuntu image with Etcher to it
    (all data on the flash drive will be deleted!)
  9. Download either a GParted live image or any live Linux distribution (I took Ubuntu amd64) and flash/write that to another flash drive or a DVD so you can boot from it
  10. Boot your computer from it while your Switch SD card is connected to the computer so it is automatically mounted there
  11. Run GParted, unmount the FAT32 partition from there so you can resize it
  12. Resize it to free up some space for L4T Ubuntu. I resized it so there were around 16 GB after it at the end of the SD card
  13. Create an EXT4 partition in that unallocated free space with GParted and hit the apply button so both operations (resizing FAT32 and creating EXT4 partition) will be done - this will take some time
  14. Download a CloneZilla Live and flash/write that to a flash drive or DVD
    I burned it to a DVD with imgburn
  15. Boot your computer into CloneZilla while these both things are connected to your computer:
    • Switch SD card
    • flash drive from step 8 where you flashed the L4T image to
  16. In CloneZilla choose the options to clone not a whole drive but only a partition to another
  17. Choose expert mode so you can untick the option (with SPACE) to resize the destination partition size to the source partition size
  18. As the source partition choose the EXT4 partition (not the FAT32 one) from the flash drive from step 8
  19. As the destination partition choose the EXT4 partition from your Switch SD card that you just created with GParted
  20. Very important: remember how the devices are labeled (for example sdb, sdc, sdd and so on)
    In my case my source device (the flash drive from step 8) was sdb and the EXT4 partition on it was sdb1
    and my destition device (Switch SD card) was sdc and the destition EXT4 partition was sdc3
    What you need to remember now is the label of your source device (the USB flash drive)
  21. Now proceed and hit Y on both warnings that all data in the destination partition will be deleted (that's fine, it's really just the partition, not the whole SD card including your created emuMMC)
  22. Most likely CloneZilla will now complain that source and destition partition tables (MBR and GPT) are not the same and you have to resolve that first
    That's why I told you to remember the label from your flash drive!
    Hit ENTER and then get into the shell/commandline and type the following:
    sudo sgdisk -z /dev/sdx
    (where you replace x by the letter that you remembered)
    In my case it was /dev/sdb (without any numbers behind it)
    Confirm all warnings
  23. Now head back to step 16 and repeat the steps to clone the drive
    It should work now without complaints from CloneZilla
  24. After that is finished, boot back into your usual operation system on your computer and copy everything from your temp folder back to the FAT32 partition that you should be able to access from there
  25. Windows might complain about two "drives" that are not readable and need to be formatted - obviously that's your emuMMC and your L4T Ubuntu partition and you don't want to format them ... just ignore the messages
  26. Download the most recent L4T update (at this time it's 1.3.1), delete the boot.scr file and the boot folder (not to be confused with the bootloader folder!), then copy the content of the L4T update zip to the FAT32 partition of your SD card
  27. On your SD card rename the Nintendo folder to Emutendo
    If you boot into the emuMMC now all games that you had installed previously are present there
    If you want them to be present in your sysNAND instead for whatever reason leave the folder by its name Nintendo
  28. Edit you're SD:\bootloader\hekate_ipl.ini to cover all your needs (CFW emuMMC, Stock sysNAND, CFW sysNAND, L4T Ubuntu, whatever else you want)
    You can find an example of mine at the end of this guide
    The emuMMC section is important as it has to be exactly like that for Atmosphère to detect it
  29. On your SD root directory create a folder called emuMMC
  30. Inside that folder create an empty text file called emummc.ini and open it with a text editor
  31. Paste into it what I put at the end of this thread and save the file
  1. Put the SD card into your Switch and fire up the hekate payload
  2. Head to emuMMC and MIGRATE - it should detect and migrate it
Congratulations, that should be it. Now you can boot everything from within hekate.
Keep in mind that the initial boot of L4T Ubuntu takes some time while the screen is black. Be patient!
Also let me give you the advice to choose different themes for your sysNAND and emuMMC. I have the white theme enabled in my sysNAND while I have the dark theme in my emuMMC environment so I always definitely know where I am.

Here's my promised hekate_ipl.ini:
Code:
[config]
autoboot=0
autoboot_list=0
bootwait=1
verification=1
backlight=100
autohosoff=0
autonogc=1
{AtlasNX/Kosmos v13.0.2}
{}
{Discord: discord.teamatlasnx.com}
{Github: git.teamatlasnx.com}
{Patreon: patreon.teamatlasnx.com}
{Pegascape DNS: pegascape.sdsetup.com}
{}
{--- Custom Firmware ---}
[CFW (SYSNAND)]
emummc_force_disable=1
fss0=atmosphere/fusee-secondary.bin
kip1patch=nosigchk
atmosphere=1
logopath=bootloader/bootlogo.bmp
icon=bootloader/res/icon_payload.bmp
{}
[CFW (EMUMMC)]
fss0=atmosphere/fusee-secondary.bin
kip1patch=nosigchk
atmosphere=1
logopath=bootloader/bootlogo.bmp
icon=bootloader/res/icon_payload.bmp
{}
[SX OS]
payload=bootloader/payloads/SX_OS.bin
[Argon NX]
payload=bootloader/payloads/Argon_NX.bin
{--- Stock ---}
[Stock (SYSNAND)]
emummc_force_disable=1
fss0=atmosphere/fusee-secondary.bin
stock=1
icon=bootloader/res/icon_switch.bmp
{}
[L4T Ubuntu]
payload=l4t-ubuntu/coreboot.rom

And here's the emummc.ini:
Code:
[emummc]
enabled = 1
sector = 0x2
nintendo_path = Emutendo

I did not test that yet so I can only assume it works, but it should!
In short, from current SD (SD1) to a bigger one (SD2):
  1. CloneZilla: Clone the whole SD1 to SD2
  2. GParted: Delete the EXT4 partition on SD2
  3. GParted: Resize the FAT32 partition on SD2 as you like but leave some space at the end for L4T Ubuntu
  4. GParted: Create an EXT4 partition out of that left unallocated space at the end of SD2
  5. CloneZilla: Clone only the EXT4 partition from SD1 to the newly created EXT4 partition on SD2 (similar to how I did it in the guide above with the temporary flash drive to get Linux onto my SD card)
 
Last edited by lordelan,

tabzer

This place is a meme.
Member
Joined
Feb 15, 2019
Messages
5,844
Trophies
1
Age
39
XP
4,911
Country
Japan
I don't know for sure, I never really used the free version.

I'm now following Tariq's new thread, and have decided to rely on gparted. I'm installing linux now. I wonder if he knows about the boot.scr details we discussed here. He's got emummc working with Android with space at the end of his sd card intended for L4T.

This is his thread:

https://gbatemp.net/threads/setup-guide-setting-up-android-with-emummc-bigger-fat32-partition.544981

With Windows 7, I had issues with being able to mounting multiple partitions from the same SD card, so I had trouble flashing images to the various partitions. Windows 10 offers better support, but still not as much as gparted/linux.
 
Last edited by tabzer,

nastys

ナースティス
Member
Joined
Aug 5, 2014
Messages
1,730
Trophies
0
Age
26
Location
Earth
XP
1,794
Country
Italy
Download either a GParted live image or any live Linux distribution (I took Ubuntu amd64) and flash/write that to another flash drive or a DVD so you can boot from it
I assume this step is only for non-GNU/Linux users?

Anyway, I agree that Clonezilla is overkill. dd (for cloning the partitions) and gdisk (for repairing the hybrid MBR) should work fine.
 
  • Like
Reactions: Deleted-172301

lordelan

Well-Known Member
OP
Member
Joined
Jan 4, 2015
Messages
5,800
Trophies
1
Age
44
XP
6,569
Country
Germany
I assume this step is only for non-GNU/Linux users?

Anyway, I agree that Clonezilla is overkill. dd (for cloning the partitions) and gdisk (for repairing the hybrid MBR) should work fine.
Yes, that's a Windows guide. If you already are on Linux you don't need a separate Live Linux. :D
Also dd is better and faster than CloneZilla. I just wasn't to familiar with it while it was pretty obvious to me in CloneZilla what I'm doing.
 
D

Deleted-172301

Guest
Going to crack at this again. Been looking forward to this all week. I’m recreating my ubuntu boot disk as well. Some driver issue caused the resolution to stay at 1024x768. Was awful lol.

Current partition setup:
Code:
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       146802687   70.0 GiB    0700  Microsoft basic data
   2       146802688       167774207   10.0 GiB    8300  Linux filesystem
   3       167774208       171968511   2.0 GiB     8300  Linux filesystem
   4       171968512       249733119   37.1 GiB    8300  Linux filesystem

I played around with Hybrid MBR. This is what that would look like using the above.
Code:
Number  Boot  Start Sector   End Sector   Status      Code
   1                  2048    146802687   primary     0x0C
   2             146802688    167774207   primary     0x83
   3             167774208    171968511   primary     0x83
   4                     1         2047   primary     0xEE

I could go forward and install L4T, but I still need to add the needed android partitions before I feel comfortable attempting a boot.

Partitions after making space for Android:
Code:
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       146802687   70.0 GiB    0700  Microsoft basic data
   2       146802688       167774207   10.0 GiB    8300  Linux filesystem
   3       167774208       171968511   2.0 GiB     8300  Linux filesystem
   4       171968512       174192639   1.1 GiB     8300  Linux filesystem
   5       174192640       178745343   2.2 GiB     8300
   6       178745344       178888703   70.0 MiB    8300
   7       178888704       179032063   70.0 MiB    8300
   8       179032064       179175423   70.0 MiB    8300
  10       179175424       249735167   33.6 GiB    8300

MBR
Code:
Number  Boot  Start Sector   End Sector   Status      Code
   1                  2048    146802687   primary     0x0C
   2             146802688    167774207   primary     0x83
   3             167774208    171968511   primary     0x83
   4                     1         2047   primary     0xEE

I found that your hybrid MBR setup breaks if you add partitions after you create that setup. So make sure you finalize your partition sizes before using gdisk to create a hybrid MBR setup. (Lucky that I figured this out before writing images)

Hekate didn't detect Fat32 after restoring all images... So might have to figure out whats going on... Fixed it. Re-rwrote the hybrid mbr setup.

So far:

L4T boots just fine.
Android gave a completely black screen. Will most likely have to review my partition order as mentioned earlier.

... Time for bed. My Ubuntu boot usb no longer boots... I have another, but its not setup for persistence.

So far I actually think my setup is fine. Need to figure out what boot files need to be modified. I’m not sure if I need to edit the boot.scr for android in my case. I created the L4T partition before android. Might be the cause of my troubles...

I thought if I kept L4T on MBR, and android on GPT. It would be enough to avoid conflicts
---
Just for fun I tried this:
Code:
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       146802687   70.0 GiB    0700  Microsoft basic data
   2       171968512       174192639   1.1 GiB     8300  Linux filesystem
   3       174192640       178745343   2.2 GiB     8300  Linux filesystem
   4       178745344       178888703   70.0 MiB    8300  Linux filesystem
   5       178888704       179032063   70.0 MiB    8300  Linux filesystem
   6       179032064       179175423   70.0 MiB    8300  Linux filesystem
   7       179175424       249735167   33.6 GiB    8300  Linux filesystem
   8       146802688       167774207   10.0 GiB    8300  Linux filesystem
   9       167774208       171968511   2.0 GiB     8300  Linux filesystem

Command (? for help): r

Recovery/transformation command (? for help): o

Disk size is 249737216 sectors (119.1 GiB)
MBR disk identifier: 0x00000000
MBR partitions:

Number  Boot  Start Sector   End Sector   Status      Code
   1                  2048    146802687   primary     0x0C
   2             146802688    167774207   primary     0x83
   3             167774208    171968511   primary     0x83
   4                     1         2047   primary     0xEE

FYI - Partitions 8 & 9 are meant for L4T. I created a 2gb swap partition. This should work, once everything else gets sorted...

However, Android still didn't boot. Will have to dig deeper. I'm sure its my partition order. I haven't actually looked at the boot.scr files to see if I need to match the sector count as well...
 
Last edited by ,
  • Like
Reactions: Cyan and lordelan

lordelan

Well-Known Member
OP
Member
Joined
Jan 4, 2015
Messages
5,800
Trophies
1
Age
44
XP
6,569
Country
Germany
Going to crack at this again. Been looking forward to this all week. I’m recreating my ubuntu boot disk as well. Some driver issue caused the resolution to stay at 1024x768. Was awful lol.

Current partition setup:
Code:
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       146802687   70.0 GiB    0700  Microsoft basic data
   2       146802688       167774207   10.0 GiB    8300  Linux filesystem
   3       167774208       171968511   2.0 GiB     8300  Linux filesystem
   4       171968512       249733119   37.1 GiB    8300  Linux filesystem

I played around with Hybrid MBR. This is what that would look like using the above.
Code:
Number  Boot  Start Sector   End Sector   Status      Code
   1                  2048    146802687   primary     0x0C
   2             146802688    167774207   primary     0x83
   3             167774208    171968511   primary     0x83
   4                     1         2047   primary     0xEE

I could go forward and install L4T, but I still need to add the needed android partitions before I feel comfortable attempting a boot.

Partitions after making space for Android:
Code:
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       146802687   70.0 GiB    0700  Microsoft basic data
   2       146802688       167774207   10.0 GiB    8300  Linux filesystem
   3       167774208       171968511   2.0 GiB     8300  Linux filesystem
   4       171968512       174192639   1.1 GiB     8300  Linux filesystem
   5       174192640       178745343   2.2 GiB     8300
   6       178745344       178888703   70.0 MiB    8300
   7       178888704       179032063   70.0 MiB    8300
   8       179032064       179175423   70.0 MiB    8300
  10       179175424       249735167   33.6 GiB    8300

MBR
Code:
Number  Boot  Start Sector   End Sector   Status      Code
   1                  2048    146802687   primary     0x0C
   2             146802688    167774207   primary     0x83
   3             167774208    171968511   primary     0x83
   4                     1         2047   primary     0xEE

I found that your hybrid MBR setup breaks if you add partitions after you create that setup. So make sure you finalize your partition sizes before using gdisk to create a hybrid MBR setup. (Lucky that I figured this out before writing images)

Hekate didn't detect Fat32 after restoring all images... So might have to figure out whats going on... Fixed it. Re-rwrote the hybrid mbr setup.

So far:

L4T boots just fine.
Android gave a completely black screen. Will most likely have to review my partition order as mentioned earlier.

... Time for bed. My Ubuntu boot usb no longer boots... I have another, but its not setup for persistence.

So far I actually think my setup is fine. Need to figure out what boot files need to be modified. I’m not sure if I need to edit the boot.scr for android in my case. I created the L4T partition before android. Might be the cause of my troubles...

I thought if I kept L4T on MBR, and android on GPT. It would be enough to avoid conflicts
---
Just for fun I tried this:
Code:
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       146802687   70.0 GiB    0700  Microsoft basic data
   2       171968512       174192639   1.1 GiB     8300  Linux filesystem
   3       174192640       178745343   2.2 GiB     8300  Linux filesystem
   4       178745344       178888703   70.0 MiB    8300  Linux filesystem
   5       178888704       179032063   70.0 MiB    8300  Linux filesystem
   6       179032064       179175423   70.0 MiB    8300  Linux filesystem
   7       179175424       249735167   33.6 GiB    8300  Linux filesystem
   8       146802688       167774207   10.0 GiB    8300  Linux filesystem
   9       167774208       171968511   2.0 GiB     8300  Linux filesystem

Command (? for help): r

Recovery/transformation command (? for help): o

Disk size is 249737216 sectors (119.1 GiB)
MBR disk identifier: 0x00000000
MBR partitions:

Number  Boot  Start Sector   End Sector   Status      Code
   1                  2048    146802687   primary     0x0C
   2             146802688    167774207   primary     0x83
   3             167774208    171968511   primary     0x83
   4                     1         2047   primary     0xEE

FYI - Partitions 8 & 9 are meant for L4T. I created a 2gb swap partition. This should work, once everything else gets sorted...

However, Android still didn't boot. Will have to dig deeper. I'm sure its my partition order. I haven't actually looked at the boot.scr files to see if I need to match the sector count as well...
Now that's some investigation.
Really nice!
Although it seems Tariq has figured it out somehow:
https://gbatemp.net/threads/setup-g...id-with-emummc-bigger-fat32-partition.544981/
 
Last edited by lordelan,

tabzer

This place is a meme.
Member
Joined
Feb 15, 2019
Messages
5,844
Trophies
1
Age
39
XP
4,911
Country
Japan
@~~Tito~~ why do you need 10 partitions? I think you only need 9 max possibly 8. 1 x Fat32, 6 x Android 1 x Emummc (partition definition isn't as important as long as the data gets written somehow), and 1 x L4T. The 1x FAT32 is shared between all systems for ofw/homebrew/bootdata.

Tariq defined his first Fat32 partition as EE and his second Fat32 partition as E0, so the Emummc partition could be seen by hekate's emummc builder.

Tariq's video lays out a useful/operating partition order, but he makes a mistake with the size of his user data partition the first time and has to redo it in the video, so if you watch the video 1 x before doing it, it's good. He also says it's important that the partitions are properly named. If you do them out of order (ie, +1/-1), then you will have to redefine the boot.scr for android in the section (untested):

(//boot)
part start mmc 1 4 aistart
part size mmc 1 4 aisize
(//recovery)
else
part start mmc 1 5 aistart
part size mmc 1 5 aisize

What does work, is if you stick L4T in the 9th partition and then use my boot.scr built for that. I will include it in the other thread.
 

Attachments

  • bootscr.zip
    365 bytes · Views: 144
  • Like
Reactions: Cyan

Cyan

GBATemp's lurking knight
Former Staff
Joined
Oct 27, 2002
Messages
23,749
Trophies
4
Age
46
Location
Engine room, learning
XP
15,662
Country
France
which size is your L4T partition ?
i think it's supposed to be 8GB, if you made a big 10GB then the partition information will be wrong.
I don't know if it has a real effect on the actual partition data. I guess as long as the partition definition is bigger than the real partition size it's fine. the real usable size is defined in ext4 header. you just waste few MB (or GB) if you make it too big compared to the 1.img size.

I don't know linux enough, what's the purpose of the 2GB swap partition? it's a temporary working partition, like more RAM?

android image has 7 partition (fat + android), why would you have L4t on the 9th instead of 8th?
didn't you do this : fat (MBR+gbt), android (gpt), l4t (mbr+gpt), MMC ?
I'm not even sure you need to have l4t on MBR, only FAT32 is required. unless L4T is specifically coded to look at MBR to mount partitions.

edit : Ah, that's because you placed MMC first and created a partition definition for MMC instead of writing it to an unallocated space (or instead of deleting the definition from the table, but then it'll be harder to add new partition after it. it's good only if it's the last partition)
but again, if you make a partition definition bigger than actual size, and one day you want to backup to image, it'll create a bigger image than real partition size. that's why I was looking at a partition manager which let us set exact byte or sector sizes to match the images.

I guess emuMMC before L4T is not a bad idea, so you can increase L4T or add new swap partition after it without worrying about overwriting emummc.
 
Last edited by Cyan,

tabzer

This place is a meme.
Member
Joined
Feb 15, 2019
Messages
5,844
Trophies
1
Age
39
XP
4,911
Country
Japan
what's the purpose of the 2GB swap partition?

It's like RAM. Not as fast, obviously.

i think it's supposed to be 8GB, if you made a big 10GB then the partition information will be wrong.

Yeah, actually, I found out that I had to use disk tool to "resize" the partition for L4T to re-purpose the space. As long as you create enough space for the image to flash, it doesn't matter if you go GiBs over. You can still re-initialize it into the system.

android image has 7 partition (fat + android), why would you have L4t on the 9th instead of 8th?
didn't you do this : fat (MBR+gbt), android (gpt), l4t (mbr+gpt), MMC ?

I had Emummc partition before L4T.

I'm not even sure you need to have l4t on MBR

Did I say something that suggested that? I don't exactly know how gdisk manages it, but the only partitions I modified were the 2x FAT32, the first and eighth partition (emummc); EE and E0 respectively.


writing to unalocated space

How can we do this? It'd be convenient of Hekate can do that with it's emummc creator, but it looks for partitions. Is there a convenient way?
 
Last edited by tabzer,

Cyan

GBATemp's lurking knight
Former Staff
Joined
Oct 27, 2002
Messages
23,749
Trophies
4
Age
46
Location
Engine room, learning
XP
15,662
Country
France
no convenient way, I'd use dd with seek command for that.
check last used sector from partition information, and then dd emuMMC starting at last used sector+1

Did I say something that suggested that?
No, you didn't. sorry if I wasn't clear.
I commented about Tito's last MBR table he provided. it contains it's 2GB partition on MBR. seeing Hekate can boot partition based on GPT position, having l4T on MBR is probably not required.


I just watched Tariq's video and it's exactly what I thought I'd do except for fixing MBR, I'd have done it using an hexeditor because I don't have gDisk equivalent on windows.

I see he adds the MMC in MBR, is that a requirement? I thought hekate could boot MMC using sector number.
well, if it works fine with MMC being in MBR as "E0" then I don't see anything wrong with that. it's even easier to write the binary to existing partition instead of skipping/seeking sectors.
is "E0" even a requirement? maybe it's for hekate detection when dumping MMC to partition? but can't it be anything else?
If not a requirement, I'd prefer guides to not suggest things, because it's a habit of end users creating guide based on wrong info, and propagating them for years (like "set active flag" for wii game backup partition, it was stupid but kept in all new guides)
I'm not saying Tariq's guide is wrong or stupid, just that if it's not a requirement we shouldn't enforce this on future guides.


Sorry, all I said so far are only supposition, as I couldn't try everything yet.
I'll see if I can make the same in windows (even if he specifically said not to).
 
Last edited by Cyan,

tabzer

This place is a meme.
Member
Joined
Feb 15, 2019
Messages
5,844
Trophies
1
Age
39
XP
4,911
Country
Japan
I see he adds the MMC in MBR, is that a requirement? I thought hekate could boot MMC using sector number.

In the end, Atmosphere uses its emummc to boot based off sector. I mentioned in that thread of my encounter which demonstrates this, outside of the *.ini configuration where you link it to the sector. As for Hekate's emummc creator tool, it does look for defined partitions, and I think that's the only reason E0 was used, even though I don't really know what that means. It could be useless, and there might be a better way. There maybe many different headers that we could use, but maybe Tariq wanted to use that because it would be easy enough to confirm through Hekate when choosing the emummc partition.

is "E0" even a requirement?

::shrug::
 
Last edited by tabzer,
  • Like
Reactions: Cyan

Cyan

GBATemp's lurking knight
Former Staff
Joined
Oct 27, 2002
Messages
23,749
Trophies
4
Age
46
Location
Engine room, learning
XP
15,662
Country
France
yeah I understand now, he put the partition in MBR to let hekate dump MMC.
I just had it wrong by thinking only about flashing my MMC from an already dumped binary to specific sector using dd or makeEmu (to flash boot0/1/user to a partition).
his method is easier.
 
Last edited by Cyan,

tabzer

This place is a meme.
Member
Joined
Feb 15, 2019
Messages
5,844
Trophies
1
Age
39
XP
4,911
Country
Japan
I'll see if I can make the same in windows (even if he specifically said not to).

I'm sure there is a way. It may not be as convenient or obvious as to how, but the more methods/tools developed for windows, the better. I spent like 6 hours trying to getting a useful Linux OS working on my desktop for the couple hours I wanted to use gparted and gdisk.
 
D

Deleted-172301

Guest
@~~Tito~~ why do you need 10 partitions? I think you only need 9 max possibly 8. 1 x Fat32, 6 x Android 1 x Emummc (partition definition isn't as important as long as the data gets written somehow), and 1 x L4T. The 1x FAT32 is shared between all systems for ofw/homebrew/bootdata.

Tariq defined his first Fat32 partition as EE and his second Fat32 partition as E0, so the Emummc partition could be seen by hekate's emummc builder.

Tariq's video lays out a useful/operating partition order, but he makes a mistake with the size of his user data partition the first time and has to redo it in the video, so if you watch the video 1 x before doing it, it's good. He also says it's important that the partitions are properly named. If you do them out of order (ie, +1/-1), then you will have to redefine the boot.scr for android in the section (untested):

(//boot)
part start mmc 1 4 aistart
part size mmc 1 4 aisize
(//recovery)
else
part start mmc 1 5 aistart
part size mmc 1 5 aisize

What does work, is if you stick L4T in the 9th partition and then use my boot.scr built for that. I will include it in the other thread.

Yeah, I only made 9. It looks like 10, but in my first go around I deleted a partition. When I redid the table it was numbered correctly.

I did skim through the video, but I didn’t see anything that I was doing differently. I wasn’t following what was in the boot.scr for android. I know that’s my mistake, but I wanted to see if it would work based on the partition order alone.

I was going to retry again, this time following the android setup exactly. I wasn’t sure if I could get away with having the data there in order. So I put the HOS data in my single fat partition, but it sounds like we do indeed need two fat partitions. I feel that is overkill.

If we know how each boot.scr works, then we should be able to write as we see fit. The only outlier that I know has to be true is to have the first partition be FAT32 for HOS and Hekate.

In my last attempt, I tried to re-order the partitions while keeping the same sector locations. That didn’t work lol
 
Last edited by ,
D

Deleted-172301

Guest
Ideally this is what I would want my partition map to look like:

[EMUMMC] - Hidden. Sector space accounted for. Each other partition will start after the emummc block.
[L4T] - GPT
[Swap]
[Android] - GPT
[1-7]
[FAT] - MBR

I played with gdisk’s ability to rebuild and reorder partitions, so I know this can be built this way first. Then you would go in and re-order as you need. The only problem with that would be if something relied on a hard mapped sector count+partition order. I don’t know if thats 100% the case right now.

I’ll play with this again later, but I’ve mostly tested what I would prefer. So my partition order is probably wrong.

I also don’t have emummc so that has to be built first. I wanted to sort out how to get the mappings right before I created an emunand partition.
 
Last edited by ,

tabzer

This place is a meme.
Member
Joined
Feb 15, 2019
Messages
5,844
Trophies
1
Age
39
XP
4,911
Country
Japan
The requirement for emunand makes it tricky. What I said before about editing Android's boot.scr is a minimal that has to be done. I don't know how the boot partition chainlinks into the next partition so it could be more involved, but worth trying. L4T is easy to manage.

Is the "Swap" for L4T?


Maybe you can do something like this:
[EMUNAND] - Hidden. Sector space accounted for. Each other partition will start after the emummc block.
[Android] - GPT
[2-7]
[L4T] - GPT
[Swap]
[FAT] - MBR (Includes data needed from Android's 1st partition-boot info)
 
Last edited by tabzer,
D

Deleted-172301

Guest
Yeah swap is for L4T. Otherwise you’d have to create a 2gb swap file within the L4T partition itself. Which seems like a waste.

Without swap space. L4T crashes quite a lot.
 
Last edited by ,

tabzer

This place is a meme.
Member
Joined
Feb 15, 2019
Messages
5,844
Trophies
1
Age
39
XP
4,911
Country
Japan
Yeah swap is for L4T. Otherwise you’d have to create a 2gb swap file within the L4T partition itself. Which seems like a waste.

Without swap space. L4T crashes quite a lot.

How is it a waste if it's going to be done one way or another? It doesn't affect performance, does it?

Also, I made a mistake I think.

I just realized that EMUNAND might not actually be a partition, and not register on the partition table. So you would need a small 1st partition before Android's 2-7. It probably can be a blank small ext4 partition with nothing on it. It would only be there to offset the count on the partition table as to not disturb it's "natural order"
 
D

Deleted-172301

Guest
How is it a waste if it's going to be done one way or another? It doesn't affect performance, does it?

Also, I made a mistake I think.

I just realized that EMUNAND might not actually be a partition, and not register on the partition table. So you would need a small 1st partition before Android's 2-7. It probably can be a blank small ext4 partition with nothing on it. It would only be there to offset the count on the partition table as to not disturb it's "natural order"

Well i’d like to have 8-7gb free for L4T. If I add swap within the partition that space gets eaten up. Adding a partition outside of the system makes sense to keep that space free. I plan on using L4T as an emergency OS that can be used on the road.

If we can get that sort of map to work, then transferring that to the EMMC chip itself would make this easier. Then all that is needed is an SD with all of its space dedicated to FAT.
 

tabzer

This place is a meme.
Member
Joined
Feb 15, 2019
Messages
5,844
Trophies
1
Age
39
XP
4,911
Country
Japan
Well i’d like to have 8-7gb free for L4T. If I add swap within the partition that space gets eaten up.

I just made the L4T partition big enough to account for the swap I wanted to assign for it. The way you wrote that makes it sound like you are either saving space from your SD card or that L4T is restricted in size.

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

Lol, here's an idea. You can probably resize and re-purpose one of Android's useless partitions for L4T Swap if you wanted. I'm in the mode of thinking that less partitions is a better situation.
 
  • Like
Reactions: Deleted-172301
D

Deleted-172301

Guest
Yeah I did want to restrict L4T to 10gb, and have swap on the side. I think file based swap has the risk of corruption. Its been years since I’ve actually needed to have swap space. From what I remember, it was a better practice just because the data is housed and read independently from the OS.
 
Last edited by ,

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    SylverReZ @ SylverReZ: https://www.youtube.com/watch?v=8ptLqnNMcQk