Last month I tried installing TWRP but the tablet didn't accept it so I had to recover it with my mother's PC.
And a WEEK ago, I tried installing LOS 21 on it after testing it in DSU, I somehow managed to soft brick it.
I mean only TWRP worked.
The only device I had was my father's Android 7 phone with almost no free storage and a 4GB SD Card.
The challenge
I was in the countryside without access to my HP ProBook 430 G6 which I got for free a month ago from some french dudes.
The firmware package is around 4GB, while my phone only had around 2GB free, so extracting AP.tar.md5 into super.img was impossible, I had no way to unpack Samsung firmware locally. Besides, cell service in the countryside SUCKED and we were still stuck at 4G in that area, so my WiFi was SLOWER.
GitHub Codespaces to the rescue
Instead of waiting until I got home, I wondered...
Why not let GitHub's servers do the heavy lifting?
So I created a GitHub Codespace and downloaded the Samsung firmware there.
Inside Codespaces I extracted:
which contained
Now came another problem.
The super.img.lz4 was BIG and the Tecno was too slow to download it directly from the codespace, and it didn't have enough space to download the file at once.
Splitting a file into parts
The next day, I split the super.img.lz4 into parts and uploaded them to GitHub using Git LFS (it didn't accept 2GB+ files so I had to split the file either way), after that I downloaded the file part by part and sent them to my SD Card.
On the tablet, I simply merged them.
Now a new problem : TWRP 3.7 couldn't extract an lz4 file, and the TWRP terminal didn't have LZ4.
Building a static lz4 binary
Instead of trying random Android binaries from the internet, I built lz4 statically.
It was the only straight-forward thing in this entire recovery, just clone the repo and run make with using the aarch64-gcc and adding the static flag, then I uploaded the 1Mb binary into the SD Card.
That way I could simply copy one executable onto the tablet and decompress directly inside recovery.
lz4 -d super.img.lz4 super.imgI was tight on time and my father wanted to watch a series on his phone so I had to rush it lol.
Flashing from recovery
Using my phone's SD Card, I transferred:
directly onto the tablet.
Then I flashed both images.
After a few attempts and learning Samsung's partition layout the hard way, I finally recovered stock firmware.
Running LineageOS without touching my stock install
One thing I wanted was to experiment without constantly reflashing the tablet.
Instead of replacing OneUI immediately, I installed LineageOS 20 bvN using Dynamic System Updates (DSU) on the tablet on my entire storage (after I removed every system component on stock), and then I rooted the DSU environment with Magisk.
That gave me the speed of GSI without risking my working installation every five minutes.
PowerVR GE8320 overclocking
PS : I broke the letter j on my keyboard, unlucky me lol
I think this is the part you've been waiting for, and seriously, the way I figured it out is *poooooof* mindblowing.
So ever since I had the tablet, I wanted to overclock the CPU and/or GPU, but modifying the cpu_freq entry in the /sys/ folders and the gpu frequency in /sys/kernel/gpu/gpu_clock didn't work, I gave up for a few months but I went attacking the subject again yesterday (August 2nd).
I wanted to tweak the system without overclocking so that it would deliver, I used LSpeed and a few other Magisk Modules like LKTweak and LSPosed Modules.
But then I decided to attack the GPU overclock again. I took a more methodological and AI-based approach.
The PowerVR GE8320 is notorious for being the worst GPU on Android, it has no documentation, Vulkan support sucks, and there are no WIPs to make custom drivers for it.
First I dumped anything that had GPU on this name :
find /sys/kernel -iname "*gpu*" 2>/dev/null
find /sys/kernel -iname "*ged*" 2>/dev/null
find /sys/module -iname "*gpu*" 2>/dev/null
find /sys/module -iname "*ged*" 2>/dev/null
find /proc -iname "*gpu*" 2>/dev/null
find /proc -iname "*ged*" 2>/dev/nullAnd I found :
Samsung (or the LOS GSI or MediaTek) (un)intetionally left this interface enabled.
We also have :
/proc/gpufreq/gpufreq_opp_dumpWhich - on a Samsung device - should be extracted from the DTB, but the kernel is ALREADY EXPOSING IT.
GED also has some interesting thingys but that we won't get into.
The /proc/gpufreq has:
*drumroll*
-rw-rw-r-- 1 root root 0 2026-08-02 20:10 gpufreq_fixed_freq_volt
-rw-rw-r-- 1 root root 0 2026-08-02 20:10 gpufreq_opp_dump
-rw-rw-r-- 1 root root 0 2026-08-02 20:10 gpufreq_opp_freq
-rw-rw-r-- 1 root root 0 2026-08-02 20:10 gpufreq_opp_stress_test
-rw-rw-r-- 1 root root 0 2026-08-02 20:10 gpufreq_power_dump
-rw-rw-r-- 1 root root 0 2026-08-02 20:10 gpufreq_power_limited
-rw-rw-r-- 1 root root 0 2026-08-02 20:10 gpufreq_var_dumpThe gpufreq_opp_dump has the full dump of the DVFS table, on my device it's like this :
[0] freq = 680000, volt = 80000, vsram = 87500, gpufreq_power = 746
[1] freq = 500000, volt = 70000, vsram = 87500, gpufreq_power = 419
[2] freq = 400000, volt = 65000, vsram = 87500, gpufreq_power = 293PS : (it turns the microvolts into millivolts and multiplies by 10 the volt to get 800 mV)
The driver also supports locking the frequency, I thought I could lock the GED and GPU to OPP 0, like a performance governor for the GPU.
BUT
The other file (gpufreq_fixed_freq_volt) contains :
GPU-DVFS fixed freq & volt is disabledWhich means that the kernel has a fixed-frequency mode that can be enabled by interfacing it correctly.
After writing:
echo "680000 80000" > /proc/gpufreq/gpufreq_fixed_freq_voltto the terminal, the system accepted it.
I wrote 690000 KHz to the file, and after running cat on gpufreq_var_dump, it showed the 690 MHz frequency. 700 MHz works as well.
Which means that the GPUFreq driver exposes a programmable PLL which can be programmed to any frequency and voltage, or overwrites the active OPP with our own frequency and voltage, ignoring completely the frequency table, opening up overclocking, underclocking, under-overvolting...
And the other thing is, that GED still thinks we're picking OPP 0 (680 Mhz based off the table), and still thinks we're running at 680MHz, but the system is running at 700 MHz, which means :
Userspace
│
▼
GED
│
▼
GPUFreq
│
▼
PLLGPUFreq completely bypasses GED and directly programs the PLL or overwrites the active OPP.
GED says : boost OPP0, GPUFreq says : Okay, oh by the way, OPP0 is 730 MHz and 790mV now.
I've downloaded glmark2 from f-droid (on my slow ahh WiFi in the countryside) and tested a few more frequencies, but glmark2 was very driver-bound and API-bound which means that I didn't see much of an improvement, for the clocks, the system is stable at 870 MHz, at 900 MHz it froze completely, but it may not be the case on someone else's chip, it's all about the silicon loto, and given that I got this tablet used and damaged on its back, it's a miracle.
The next day I tried 3DMark, and I got +100 on the score per every 50MHz overclock in Sling Shot.
Grabbing the Samsung kernel to see why this works
I went to the gta7lite organisation on GitHub, which hosts the kernel for the Tab A7 Lite (all models), I've cloned the android_kernel_samsung_mt6765 (since there is no real difference between mt6765 and mt6768 or mt6779, besides the repo hosts the GPUFreq driver source code for all 3 chips).
After cloning, I cd-ed into drivers/gpu/gpufreq/mt6765, and looked at the files.
Samsung NEVER checked if the requested clock matched a clock in the g_opp_table, the proc interface is bypassing the governor and controls the GPU directly.
Caveat: Not every device, or maybe not every model has a Mediatek validation interface exposed, but since this is a standard MediaTek framework, some devices may work.
I inspected :
mt_gpufreq_fixed_freq_volt_proc_write();and
and
And what I found gave me a clear picture of why it worked :
Look at this snippet:
if (g_fixed_freq_volt_state) {
target_freq = g_fixed_freq;
target_volt = g_fixed_volt;
target_idx = 0;
target_cond_idx = 0;
}It simply writes the frequency, it's NOT checking anything against the OPP table:
user input
↓
target_freq = user_input
↓
__mt_gpufreq_set(...)and __mt_gpufreq_set simply applies the frequency applied to it. That's it.
AND in __mt_gpufreq_clock_switch():
dds = __mt_gpufreq_calculate_dds(
freq_new,
post_divider_power);It calculates the divider, without checking the frequency table.
The driver updates the frequency in the kernel, and completely computes the PLL frequency mathematically based on dividers.
Which means : The Samsung devs never added checks and that way, any rooted user can program the GPU PLL to any frequency and give the GPU ANY VOLTAGE.
TLDR : here is the command :
echo "750000 79500" > /proc/gpufreq/gpufreq_fixed_freq_voltIt multiplies the 79.5 mV that you would get by 10 and get 795 mV.
Sets the GPU at 750 MHz at 795mV
What's next?
First : Can we do it on the CPU ? Short answer : No--t yet.
Unfortunately, /proc/cpufreq is read-only and doesnt accept any values outside the CPU frequency table, but it can be patched through extracting the frequency table from the DTB and modifying it and repacking it and flashing it, but I don't have much time to do that since my parents want to beat me because I took the tablet for far too long.
I want to make a tool called gputil, which overclocks, underclocks, undervolts the GPU and adds a monitor for the frequency.
What started as "I just want to recover my tablet" somehow turned into building Linux utilities in the cloud, recovering Samsung firmware with nothing but a phone, wanting to overclock and tweak, and successfully pushing the PowerVR GE8320 well beyond its stock clocks. Somehow no one found this.
