First EMMC controller brick
That was the last thing i could have expected
Last updated
That was the last thing i could have expected
Last updated
I was trying to create a dualOS environment for vita, the goal was to have two separate firmware installations on one console where both could be updated/downgraded/homebrewed at will and switching between them would take only a few seconds.
The simplest way to do it was to:
edit the EMMC's Master Boot Record limiting the space that user partitions take (2.5GB) to around 750MB and assigning the rest to an "unused" partition id; that will be masterOS MBR.
copy the current OS to the "unused" EMMC area and edit MBR pushing all partition offsets by the "unused" partition offset - effectively redirecting all partitions to the "unused" area; that will be slaveOS MBR.
store first 0x30 sectors of masterOS and slaveOS somewhere (MBR sector, enso emuMBR sector and finally enso itself - 0x2E sectors).
At this point i already encountered a problem - the sdif driver would refuse to read data if read_start < vs0_start < read_end and would throw an error printing all the partitions. A small offset patch to the installer fixed it, but i took a mental note that something fishy was going on there.
It was a success, the console booted fine after the MBR edits and i was getting ready to swap from masterOS to slaveOS.
masterOS<->slaveOS switching worked by:
backing up the current first 0x30 sectors to the safe area
removing firmware checks on bootloaders
flashing the targetOS 0x30 sectors to EMMC at offset 0
Obviously everything had CRC checks in place to make sure it didnt flash broken data.
This time i didnt want to risk my console - a nice user on the HENKaku discord server offered to test it on his PS Vita knowing well that it may end up bricking his device.
The console booted, slaveOS was running. I couldnt wait to try it out so i switched to slaveOS on my Vita too, i was amazed that everything worked just fine.
I asked the tester to update the console while running slaveOS - to make sure that both firmwares are truly independent. It bricked. The console did not reboot after the update.
I was clueless, i previously checked every single update module to make sure that it does not have hardcoded offsets of any partition, so now i had no idea what exactly happened.
I decided to update my vita's slaveOS via fwtool and... the console booted just fine. I downgraded it back to 3.65, the console still worked just fine on slaveOS. I put it back on my desk and started reversing the bootloader looking for the possible brick cause.
When i tried to wake up my vita... it didnt respond - no LED, nothing. It did not reboot, even removing the battery didnt help, my vita was now dead too.
I have no idea what happened, it seems that:
if some partition offsets (?bootloaders?) are different than hardcoded when going to sleep or performing a soft reboot some flag gets set in the EMMC controller
hard boot/reboot are not affected by partition offsets
the console does not even boot to stage2 bootloader
power cycling syscon/battery controller/EMMC controller does not help
If i ever get an explanation or more detailed info i will update this page.
