[MTCD Software Development] blala:
First of all, congrats for the work!

DISCLAIMER:

I don't own ModInstaller, i have never bought a copy of it and i don't intend to do so.

Analysis is purely done from Youtube videos, open source code analysis and existing and openly available binary images.

I was working to figure out how to make a FLOSS alternative to ModInstaller.

The issues i found in all my attempts are the following:

- A6 recovery is the only one that can boot from SD Card (which can then be used to flash A9 -> A10 with the 2SD trick)

- (it took me a long time to pull these information together and unbrick my unit)​

- The A6 recovery is unable to directly flash A10 RKAF/RKFW images (sdupdate.img) due to the code being too old

- a failure will be observed while writing super.img. This happens because the device needs to be repartitioned, and the A6 recovery is not doing it correctly​

- A9 recovery is buggy. Booting it with no system installed will result in a black screen.

- it will only boot succesfully after being written by the A6 flash tool, which writes the "misc" partition with the recovery commands to run (the "hint" i get from this is that the misc partition is important)​

- A10 recovery can't be loaded by the A6 recovery. I always got a black screen after flash. Is it a flash issue? is it an issue with the recovery itself? hard to know

Theory: maybe the recovery could be written over the kernel partition? ("boot")

This way, the recovery will always run after being flashed instead of requiring an explicit "enter recovery" trigger (buttons, misc partition, etc.)

Besides these experiments, in parallel, i did some bug fixing to this repository: https://github.com/liftoff-sr/rockchip-tool/commits/master (i'm "smx-smx")

That allows me to unpack nad repack "sdupdate.img" , "reduced recovery images" and "full IMG files".

With those tools. i tried to swap "recovery.img" in the A6 image, but i always got the black screen upon booting from SD.

Either A9/A10 breaks sdboot or the bootloader crashes before it gets there.

Since this also happens when being flashed, this could either be a bug in the flashing program or a bug in the boot stack (which fails to run recovery perhaps due to a dirty state of the internal flash). It's hard to know for sure without having a UART connection with the board.

BUT, we have an alternative, in the form of the recovery built-in ISP flash tool.

This is the code that reads "sdupdate.img" from the SD Card and flashes it

After reading the recovery source code, i realised that this code can only be triggered correctly when booting from the SD card.

It detects this state by reading /proc/cmdline and probing for specific values (https://github.com/rockchip-android...6f72b7d3123dab27135ac41d55029/sdboot.cpp#L206)

This means the bootloader can (and will) pass those arguments under specific conditions (https://github.com/rockchip-linux/u...c873f178c/arch/arm/mach-rockchip/board.c#L358)

If you check here https://github.com/rockchip-linux/u...3f178c/arch/arm/mach-rockchip/boot_mode.c#L47 you can see the magic word that needs to be written to the "misc" partition in order to trigger that code.

Note that, besides the well known "sdboot", "usbboot" is also possible.

I'm not sure if the ROM can physically boot from USB, but the bootloader and recovery do support (according to code) passing the flag to enable flashing from USB.

So, recapping, there are these ways we can try:

a - try to overwrite "boot" with "recovery" (but it might not work due to the partitioning layout, e.g. jumping from A6 -> A10)

- note: uboot might also need to be written when doing this.

b - making a modified "sdupdate.img" that flashes recovery on top of boot, and all the other core partitions like "misc", "uboot", "trust", "vbmeta"

c - writing "misc" from android in order to triggers the "rkfwupdate" mode

d - taking a dump of the first portion of the flash in various states (A6, A8, A9, A10), and having a "dd" that writes it back to the beginning of the flash (i suspect this is how ModInstaller does it)

Considering cases "b" and "c" depend on a recovery that can write them correctly (and the A6 one is buggy), this leaves us with "a" and "d"

Considering that ModInstaller does it in one shot, and doesn't seem to matter about the partitioning layout, i believe "d" might be the most viable option...

Using the "rockchip-tool" repository i linked from github, the partition table can be dumped from any .img file

You can observe "Image/parameter.txt" from the extracted firmware

This is the partition table from A6's recovery:

0x00002000@0x00002000(uboot)

0x00002000@0x00004000(trust)

0x00002000@0x00006000(misc)

0x00008000@0x00008000(resource)

0x00010000@0x00010000(kernel)

0x00002000@0x00020000(dtb)

0x00002000@0x00022000(dtbo)

0x00000800@0x00024000(vbmeta)

0x00010000@0x00024800(boot)

0x00020000@0x00034800(recovery)

0x00038000@0x00054800(backup)

0x00002000@0x0008c800(security)

0x00100000@0x0008e800(cache)

0x00500000@0x0018e800(system)

0x00008000@0x0068e800(metadata)

0x00100000@0x00696800(vendor)

0x00100000@0x00796800(oem)

0x00000400@0x00896800(frp)

-@0x00896c00(userdata)

And this is the partition table from A9's recovery

0x00002000@0x00002000(uboot)

0x00002000@0x00004000(trust)

0x00002000@0x00006000(misc)

0x00008000@0x00008000(resource)

0x00010000@0x00010000(kernel)

0x00002000@0x00020000(dtb)

0x00002000@0x00022000(dtbo)

0x00000800@0x00024000(vbmeta)

0x00010000@0x00024800(boot)

0x00020000@0x00034800(recovery)

0x00038000@0x00054800(backup)

0x00002000@0x0008c800(security)

0x00100000@0x0008e800(cache)

0x00500000@0x0018e800(system)

0x00008000@0x0068e800(metadata)

0x00100000@0x00696800(vendor)

0x00100000@0x00796800(oem)

0x00000400@0x00896800(frp)

-@0x00896c00(userdata)

Notice how uboot, trust, misc, resource, kernel, dtb, and others live in the same space. (2000, 4000, 6000, 8000, 10000, ...)

What we could do is create a raw blob that spans that address range, and "dd" it directly to /dev/mmcblk0 at the right offset.

So i would focus on converting recovery images to raw blobs, with recovery-as-kernel so it boots straight away on the first try.