IMC on GC-SD HFW (emunand)

[dogtopus]

Is this even possible? I tried to modify the MBR of emunand using mbrtool (after fixing some bugs that stopped me from making partitions > 4GB) but it doesn't seem to work. IMCUnlock modifies the sysnand instead.

The use case for this is pretty obvious: to reclaim leftover space on the emunand SD card so xmc will not be required at least when using emunand.

[dogtopus]

OK I thought it was like 3DS emunand but apparently not. Apparently only partitions necessary for OS function were redirected to the SD card (not even ur0).

[SKGleba]

Depends what you redirected. I am pretty sure that the default version redirects all partitions/sectors after bootloaders.

[dogtopus]

I am pretty sure that the default version redirects all partitions/sectors after bootloaders.

Doesn't look like so. That region only covers both oses, sa0, tm0and vs0. The clone tool also stops after vs0. Am I missing something?

[SKGleba]

Oh yeah! Just remove the '< 0xd8000' checks from both read and write hooks and it will redirect the whole emmc.

And if you want to redirect the MBR too just remove the sector 1 rw redirects.

[dogtopus]

OK so I modified the script to remove the read/write conditions. ur0 is now redirected. However the Vita still didn't recognize the added IMC (format shows only XMC).

My current MBR looks like this mbr.zip. Did I miss anything?

[dogtopus]

Output from fixed mbrtool:

$ ./mbrtool mbr.bin all -info

MBR:
 Sony Computer Entertainment Inc.
 version: 3
 device size: 60906(MB)

Partitions:
0)
 name: idstorage(0x1) active=0
 offset=(MB)0 size=0(MB)
 type=raw(0xDA) flags=0x00000f1f

1)
 name: slb2(0x2) active=0
 offset=(MB)8 size=4(MB)
 type=raw(0xDA) flags=0x00000f0f

2)
 name: slb2(0x2) active=1
 offset=(MB)12 size=4(MB)
 type=raw(0xDA) flags=0x00000f0f

3)
 name: os0(0x3) active=0
 offset=(MB)16 size=16(MB)
 type=FAT16(0x6) flags=0x00000f0f

4)
 name: os0(0x3) active=1
 offset=(MB)32 size=16(MB)
 type=FAT16(0x6) flags=0x00000f0f

5)
 name: sa0(0xC) active=0
 offset=(MB)48 size=96(MB)
 type=FAT16(0x6) flags=0x00000fff

6)
 name: tm0(0x6) active=0
 offset=(MB)144 size=32(MB)
 type=FAT16(0x6) flags=0x00000fff

7)
 name: vs0(0x4) active=0
 offset=(MB)176 size=256(MB)
 type=FAT16(0x6) flags=0x00000f0f

8)
 name: vd0(0x5) active=0
 offset=(MB)432 size=32(MB)
 type=FAT16(0x6) flags=0x00000fff

9)
 name: ud0(0xB) active=0
 offset=(MB)464 size=256(MB)
 type=FAT16(0x6) flags=0x00000fff

10)
 name: pd0(0xE) active=0
 offset=(MB)720 size=304(MB)
 type=exFAT(0x7) flags=0x00000fff

11)
 name: ur0(0x7) active=0
 offset=(MB)1024 size=2612(MB)
 type=exFAT(0x7) flags=0x00000fff

12)
 name: ux0(0x8) active=0
 offset=(MB)3636 size=57270(MB)
 type=exFAT(0x7) flags=0x00000fff

13 is empty
14 is empty
15 is empty

exit status: 0x0

[SKGleba]

Did you remove the sector 1 redirects? Try copying sd sector0 to sector1. You may also try dumping the MBR from vita to see if it redirected fine.

[dogtopus]

Yes I removed all the redirect conditions including the sector 1 special treatment (see https://github.com/dogtopus/psp2hfw/blob/full-redirect/scripts/sector_redir/sector_int2ext.c). I also synced both MBRs on my SD card but no dice. ~~Also for some reason IMCUnlock's dump feature still shows persumably sysnand MBR without the IMC partition.~~ IMCUnlock is able to dump the emunand MBR and read the modified eMMC size (although wrongly due to the same bug as mentioned earlier) but imc remove lock status is 0 if that means anything.

[SKGleba]

I am currently working on enso_ex v4.5 which is very different. I will see what i can do but most likely after v4.5 goes up.

[JesusXD88]

Any more news on this? Would be great to install the whole system on the GC-SD