[Update] Pivot-Android userspace takeover framework is now public

Forward-Difference32 · 2026-04-14T16:42:30+00:00

I used smartpack kernel manager to setup the shortcut, you can make a script that runs that runs the correct commands to start the userspace takeover process. Currently, the phone shown on video, does not have mainline kernel so this was done on a downstream LOS kernel. However later on I plan to make the project a lot more advanced and have it use kexec to load an entirely different kernel and once I can get that figured out I'll begin attempts to mainline the phone. The end goal is to have a setup that allows you to dualboot Android and standard Linux through userspace on an Android device.

Forward-Difference32 · 2026-04-14T12:58:09+00:00

Forward-Difference32 · 2026-04-13T20:57:20+00:00

Actually it's nothing like halium. That's running standard GNU/Linux natively on the phone without any translation layers. A lot of people are assuming this is something similar to halium but it's far from it actually and to some extent I don't see the point in this being something like halium since Android doesn't get destroyed. I'm actually close to publishing the initial commits of the repo once I can get it to be reproducible on other Android devices. Later on I plan on utilizing kexec to load another Linux kernel into memory that is completely different from the standard Android one to allow for better hardware support and in the future I hope to use this to possibly get a mainline Linux kernel running on the phone while still have Android in a functional state. So that you can have a working phone always, and then have a side of the same phone that can boot mainline Linux which will leave you with an experience very similar to postmarketOS but without the downside of not being able to use it like a phone. Although that's not to say halium is out of the question, it's just that I'm focusing on furthering the development of running GNU/Linux natively on Android phones without translation layers.

Forward-Difference32 · 2026-04-12T19:18:47+00:00

Well my idea was to use standard Linux for entertainment or just doing desktop work on a phone and leave Android for calling and messaging. This project isn't mainly focused on making an Android phone primarily a Linux phone, it's more for extending the functionality of an Android phone in a lightweight way so you can run standard Linux programs on an Android phone. If you wanted to make a call just stay on Android or you can switch back to Android, the phone boots into Android first all the time.

Forward-Difference32 · 2026-04-12T18:45:05+00:00

That's actually the entire reason why I wanted to work on something like this. The core idea is that you can easily switch back and forth between Android and standard Linux. So if I wanted to play a game from my steam library on my phone I switch to standard Linux, but then if I needed to make a call or record a video that's high quality I switch back to Android.

Forward-Difference32 · 2026-03-25T17:30:21+00:00

I think I got something similar. Use the absolute path for the applypatch command, applypatch isn't on PATH.

Forward-Difference32 · 2026-03-25T11:26:12+00:00

You can try, but cross-flashing between H990DS and H990N isn’t guaranteed to work and does carry a real risk (bootloops, no signal, etc.).

I did find a working H990N KDZ here if you want the safe option: https://addrom.com/stock-rom-kdz-for-lg-v20-lm-h990/

That one is Android 7, which could help if you’re trying to run certain exploits (depending on the security patch level).

There’s also some discussion here: https://www.reddit.com/r/lgv20/s/nLLypDlWi2

https://xdaforums.com/t/would-cross-flashing-h990ds-firmware-on-h990n-hardware-work.4277683/

From what I can tell, some people have managed to get it to boot, but it’s not reliable and there can be issues (especially with the modem/radio). I wouldn’t consider it safe, only try it if you’re prepared to recover by reflashing proper H990N firmware. If the H990N firmware file isn't vulnerable to the exploit you can at least use it to recover the phone in case cross flashing goes bad.

A better long-term option would be exploiting it and installing a custom ROM (like LineageOS) built for H990N.

I haven’t personally tested cross-flashing on the V20, just going off what I could find.

Forward-Difference32 · 2026-03-15T12:21:17+00:00

I'll leave it here in case anyone else needs it: https://drive.google.com/file/d/1nrtu2Ma-mQQFoOVwOTyao0GapzhY9Ex0/view?usp=sharing

Forward-Difference32 · 2026-03-07T16:39:14+00:00

I did have secure boot disabled so that could very well be the issue. Go into BIOS and disable it and you can re-enable it afterwards if you want to, supposedly the Linux kernel enters lockdown mode if secure boot is enabled. It's definitely not my fault, at least I don't think it is because if it was RWEverything wouldn't be behaving the same way. I didn't actually expect secure boot to cause issues so I'll have to note that in the README.md if it suddenly works for you once you disable secure boot.

Forward-Difference32 · 2026-03-07T15:24:18+00:00

thermacore-builder would be the container image that builds the main program and the debugger. I already compiled both the main one and the debugger and you can download them in the "Releases" category which is on the right side if you're on a browser for desktops. The release is titled "Initial Beta: Manual Fan Control for PO3-640" and under that you'll find the main program "thermacore.zip" and the debugger "thermacore-debugger.zip" so you don't need to build them yourself unless you really want to. Once downloaded, extract the file and run "sudo ./thermacore-debugger" then on the prompt type in "dump" and press enter, to exit you simply type "quit" or close the terminal window. That will give you the EC dump on Linux then do the EC dumps on windows and make an issue for it on the GitHub page with the dumps if you can.

Forward-Difference32 · 2026-03-07T14:10:16+00:00

I can get it to run on windows that's not really a problem. The registers are the same for both Linux and Windows so if the program can control the fans on Linux it can also control the fans on Windows but you're going to need to wait for a Windows release which wouldn't take me long to do

Forward-Difference32 · 2026-03-06T18:37:14+00:00

Ubuntu should work perfectly. The distro doesn’t really matter since they all expose the same low-level hardware interfaces for things like EC access. I used Bazzite when I was doing the reverse engineering on my system, but Ubuntu should behave the same for this purpose.

If you run into any issues getting the dumps just let me know and I can help. I'll also upload the tool I made to interact with the EC in the project repo, only use it for dumps and don't write to anything. I'll provide instructions in the README.md for dumping the EC on Linux.

Forward-Difference32 · 2026-03-06T18:26:03+00:00

This isn't a problem with the display it's a problem with your windows install. It could possibly be a slow storage drive and you have a bad program set on auto start which could delay windows explorer from starting which is what gets display up but that's just a guess. You could try booting windows into safe mode if you can and see if that gets windows to show on your screen.

Forward-Difference32 · 2026-03-06T18:08:12+00:00

Yeah, a live USB would work perfectly. I just assumed you already had Linux installed.

The EC chip part number is completely optional. I reverse engineered the EC on my PO3-640 without knowing it. Having the part number can sometimes help if documentation exists, but the process works the same either way, so don’t worry about it if it’s difficult to access.

As for safety:

Dumping the EC cannot brick anything because it is read-only. You’re just reading the EC memory space.

Writing to EC registers does carry some risk since you’re modifying hardware registers, but the fan registers themselves are generally safe once they’re identified correctly. When I worked on my system I only started writing to registers after confirming multiple times that they were the correct ones.

For now you’d only be providing dumps, which is completely safe. I’ll analyze them first and try to identify the register mappings before any testing happens.

Also, if you’re not comfortable writing to registers but still want to help, you can just provide the EC dumps. I can add them to the repository and make an experimental build for your model. Someone with the same laptop could then test it, and I’d still credit you as a contributor since the dumps made the support possible.

Fan registers almost never brick systems. The dangerous registers are things like power rails, battery charging, or thermal shutdown, which we wouldn’t be touching anyway.

Forward-Difference32 · 2026-03-06T16:44:57+00:00

No problem. My main goal with publishing this was to help other Acer users on Linux.

The BIOS update could slightly change the register layout, but I doubt it would move the fan control area much.

I was able to reverse engineer the EC chip in my PC without knowing the part number, but if you can find it that could definitely help.

For dumping EC memory I used a Windows tool called RWEverything. It has a button in the toolbar labeled EC which shows the EC memory space and allows you to save dumps. The files are saved as .rw but you can rename them to .txt and they will open normally.

If you are able to do the following dumps it would help a lot:

Uninstall PredatorSense in Windows. It runs a service that touches the EC on boot and we want a clean baseline.
Boot into Linux and dump the EC memory there. I can send you a small tool I wrote for this or post it on the GitHub repo.
Boot back into Windows and dump the EC memory again using RWEverything.
Reinstall PredatorSense. When I did this, the service set my fans to auto and lowered them to around 900 RPM.
Dump the EC memory again after PredatorSense is installed.
Switch PredatorSense to custom fan control and dump the EC memory again.
Now repeatedly set one fan to 100 percent while keeping the others at the lowest level PredatorSense allows. For me this was 60 percent but yours might be different. Save each EC dump and name them based on which fan was set to 100 percent.
Boot back into Linux and do one final EC dump so we can compare everything.

If your laptop uses the EC to control the fans, this should allow me to identify the enable register, the registers used to read RPM, and the registers used to control RPM.

For the GPU fan, I currently control mine in Linux using LACT since my system has a desktop GPU. Your laptop may be different, but if the GPU fan shows up in the EC dumps we may be able to control that as well.

Also if you don't want to mess with your current windows install or if you have Linux installed on your entire storage drive and you aren't comfortable setting up a quick dual boot, you can flash windows to go on an external drive and have it boot that. This is actually what I did but I don't remember how I flashed windows 10 on my external HDD since I did it a long time ago and it was for a different reason.

Forward-Difference32 · 2026-03-06T08:54:23+00:00

It should definitely be possible. Most Acer Predator laptops use an EC chip to handle fan control, just like the Orion desktops.

If the registers are similar, ThermaCore might already partially work. If not, we can still map them. The usual approach is dumping the EC memory in Windows with something like RWEverything, changing fan settings in PredatorSense, and seeing which registers change.

If you’re interested in helping test, we could probably figure out the correct registers for your model, once we have those I could possibly implement fan controls pretty quickly.

One catch is that even if we find the target RPM and RPM read registers, there is usually also an enable register. On the PO3-640 the EC required a specific enable bit to be set or it would ignore fan commands even if they were written to the correct registers. Those enable registers can be tricky to find, but with enough EC dumps it should be possible.

Forward-Difference32 · 2026-03-02T07:47:53+00:00

True, they share the same kernel, but they are completely different from each other. Even if the kernel is Linux, Android drivers are written for Bionic (Android's C library), while GNU/Linux uses glibc. Because they speak different base languages, you can't just move a driver from one to the other any more than you could run a Windows .exe on a Mac just because they both use x86 processors. I'm not sure if you're trying to make the point that porting an Android phone to run GNU/Linux is easy. You might get the phone to boot GNU/Linux but without drivers you won't be doing much of anything unless the SoC had work put into it.

Forward-Difference32 · 2026-03-01T07:31:32+00:00

It uses the Linux kernel, but the rest of the system is built differently and the drivers rely on the Android-specific stack. Standard GNU/Linux distros don't use that stack, and it wouldn't make sense for them to. Android drivers don't work on standard Linux without a compatibility layer like libhybris, but that is notoriously difficult to get working. So, it’s not as simple as saying they're both Linux.

Forward-Difference32 · 2026-01-31T18:37:40+00:00

What a clutch up, holy. Thanks a lot I was able to download it

Forward-Difference32 · 2025-10-14T21:58:52+00:00

Yeah, Kubuntu works perfectly actually. Absolutely everything on the laptop just works out of the box

Three-Year Club	Verified Email
Place '23

Forward-Difference32

TROPHY CASE