Connect the cable and that's the serial output of bootloader & kernel via type C

As I doubted

Bootloader sets debug props that fuck with kernel drivers to make it behave that way to cmdline

So, MTK fastboot and BROM/Preloader can check preloader's partition type. When you give it preloader.bin, it'll read existing preloader, and seek to after the header to then start overwriting from there. Pretty neat.

Yep, as expected, there is no funky footer/sig inside the preloader partition. It's literally just the preloader bin appended to the header. hexdiff of generated_preloader_ufs.img and the partition dd'd out: (where generated is using cat header_ufs preloader.bin > generated_preloader_ufs.img)

im actually epic at commit messages

So, Xiaomi's r16p0 Mali driver had changes weirdly knit in from r18 and r20. Thankfully, it wasn't too hard to port and get r20 working, thus :D

new driver new blobs yay

That's one angry driver

Charging -1% hahayes

Well, Realme just made my life a lot easier. They released Realme 6 sources, which contains the 11.17 mali bifrost driver! Xiaomi still hasn't opensourced the kernel they use on their A10 builds :/

So at least gralloc doesn't scream anymore

Just everything else does xD

Update, sound and adsp, fingerprint and Bluetooth work now, and the device doesn't reboot itself after every few minutes :D
The reboot was due to adsp; the new blobs didn't like the older adsp driver and the new adsp driver failed to init adsp on the older audio_dsp.img 😆 With this fixed, I can no more use recovery without updating it's kernel lmao. The old kernel inits the new dsp nicely, but fails at usip_send_emi_info_to_dsp making adsp_A_wdt_handler reboot the device.

So now I have more than -1% battery lmao

hahayes

moar fix