Use the fastboot oem ultraflash command for flashing large partitions

[jsoltan226]

After disassembling the bootloader for Mt6765 called lk.bin, I found the fastboot command "oem ultraflash", and after testing on my mt-6765 phone, it appears to allow for USB bulk transfers of large partitions. It flashes the system.img (~6GB) in about 2-3 minutes. After some research, this command is aparrently a mediatek feature and should be available on the Rabbit R1, unless the OEM specifically disabled it. I don't have a Rabbit R1 to test this out though, nor do I know anyone who does, so I'm not 100% sure if it will work.

To use this command you first enter: fastboot oem ultraflash_en 1, then fastboot oem ultraflash:system_a, and finally fastboot flash system_a system.img.

Note that from my experience (with my Oppo A12 Mt6765 phone), the first command entered after rebooting to bootloader is rejected with the 'Unknown command' error (with the exception of the "flash" command for some reason), but simply entering it a second time should work.

Also, you can unlock the bootloader directly in mtkclient by using "mtk da seccfg unlock", and wiping userdata won't be necessary in that case :)

[AgentFabulous]

Is oem ultraflash available in fastbootd? Are you sure it is able to handle super resizing the way fastbootd inbuilts do?

mtk da seccfg unlock often yielded false dm-verity failures on my end. I opted for frp since:

1. flashing unlock is fully implemented in lk still
2. I'd like to release an approach that doesn't use mtkclient in the near future, and I really don't want to sit and understand how seccfg works :)

[jsoltan226]

I don't think it's possible to go without mtkclient, as flashing partitions in lk is disabled when frp lock is on. I also don't think the ultraflash command is available in fastbootD, because it's a mediatek thing, so it's implemented in the bootloader (lk) (fastbootD is in recovery, so it's implemented by the OEM, not the board manufacturer).

Also, the way bootloader unlocking works in mtk is the unlock bit is stored in the seccfg partition, and if it's set to unlocked, the PreLoader skips verifying the TEE and LK, and later LK skips verifying the vbmeta, which contains signatures of boot and recovery partitions and root hashes of system, vendor and other dm-verity partitions. When lk complains about 'dm-verity' error, it actually just means that verification of boot/recovery failed, it has nothing to do with actual dm-verity, as it is implemented in the linux kernel driver and in the userspace init.

The only thing that fastboot flashing unlock does is it checks the unlock_ability bit in frp, the sets the unlocked bit in seccfg and wipes userdata. mtk da seccfg unlock just sets the bit in seccfg, without checking frp and without userdata wipe