Debloating HyperOS 1 (as much as possible)

Xiaomi has been pushing towards full lockdown of their phones the past year, just like Samsung. The difference is that Xiaomi is smarter at this game. Their business practices are definitely shady - relying on selling phones with minimal profit and then filling them up to the brim with bloatware that makes them money, like tons of preinstalled games and useless applications, as well as system programs filled with ads that you’re not intended to disable.

First steps of mainlining a random ARM64 phone

Android devices (the older, the worse) typically ship with outdated Linux kernels (usually up to 4 years old). As these are meant to be used with an Android environment, there are lots of HALs and blobs that cannot work outside it, rendering a lot of the deivce peripherals useless - unless you use Hybris, but that’s not ideal. This leaves us with only one rational choice - getting the mainline Linux kernel to work.

Adventures with the Volla Phone Quintus - part 1

Initial efforts #

Following the standard procedure, I first started by unlocking the phone bootloader, which was easy. I flashed a verity disabled vbmeta and I was ready to start experimenting with custom boot images.

LK expects a gzipped kernel image and a valid dtb that it can append a dtbo to. Unfortunately, the device has two very annoying quirks:

• LK has its own device tree and needs to apply the dtbo. That means you can’t just erase the dtbo partition.
• The dtbo has 300 lines of required nodes for LK to boot, which means that making it apply to a mainline device tree will be ugly.

Therefore, the approach I’m taking is to use a secondary bootloader (loaded as a kernel image by LK), which later on can boot mainline linux without the ugliness. This is the command I used to make a boot image:

Finding the reason behind the infamous S22 boot loops

Issues #

As some of you may know, there’s been quite a lot of issues with the S22 lineup - from screen defects appearing out of nowhere to phones suddenly starting to crash and boot loop, with close to no information regarding the issues apart from posts here and there. If you don’t want to read about specifics of how I found the problem and how I fixed it (in a way that’s not not preferable), skip to the end of the post for a conclusion.

Bringing Mainline Linux to life on ATM7051 handhelds

A bit of history #

I’ve been working on SoC and device bringup as a Linux kernel hobbyist for a while now (~4 years). One or two years ago, I got my hands on a handheld device called Powkiddy X51. Of course, I did not intend to use it as-is. That’s boring. So naturally, I started messing with it as sonn as I got it. At first, there wasn’t much I could do: the system firmware files were stored on its NAND, and I couldn’t find any exposed UART ports. I tried running a small custom arm binary to write to the framebuffer, but that didn’t work, so I abandoned any further work.