What I'd like to know is what software runs adequately under it in 4 GB RAM. Web browsing should definitely be possible, but I suppose it's limited to very few tabs. Some very lightweight DE could likely make it more usable. Running something like WezTerm + tmux as the DE could be even more economical, leaving some room for e.g. development tools.
Firefox is actually pretty good in low-memory situations, silently discarding tabs when under memory pressure, but the main benefit comes from being able to run proper adblocking. Chromium-based browsers just can't compete these days.
Otherwise, a bog standard Gnome-based Debian Trixie desktop should be pretty doable. I'm currently using an 8 GB machine with 3.7 GB RAM free - Firefox, evolution, gnome-calendar, and gnome-software are the only apps that using more than 100 MB, and none of them are obligatory.
Once the news gets out about epic breakthroughs on commodity hardware and devices, there's unfortunately a likely spike in the purchase cost, even if such devices can be found at all anymore on the usual online sources of new and used goods.
- Bookworm rather than Trixie looks like a conscious choice. Does 13 (either via apt upgrade or direct installation) not work?
- What's the performance of this hardware like? I've got an old Samsung tablet that's not rootable and it's really creaking on recent android. I'd much rather something like this, but I don't want to swap one too-slow thing for another.
> I suppose it's limited to very few tabs
Not really. Haven't used it super heavily, but I haven't felt limited by tabs. It can handle multiple YouTube tabs, too.
> Some very lightweight DE could likely make it more usable. Running something like WezTerm + tmux as the DE
I use sway on it. It's perfectly responsive. I expect i3 with Xorg would also be. Neither count as a DE, but neither does a terminal + tmux.
The key is to have downstream sources and be very very conservative with the AI, slowly build step by step.
You also have to know C and have a spider sense of what's acceptable or not.
Another key is to ask for approval before editing any source with a patch of what it intends to do. This way you can judge what it wants to do and ask for a double check of the patch. Go quality over quantity.
This isn't web frontend with Tailwind, you have to be very strict and somewhat knowledgeable. Nobody can use AI to write kernel code without some good low level and engineering knowledge.
No BSP, no kernel source, no vendor documentation ā just a DTB extracted from the stock Android firmware and rebuilt from there.
The tablet boots Linux directly from SD without modifying internal Android storage. Remove the card and Android still boots normally.
The process is intentionally simple: write the image to an SD card from any operating system, insert it, and boot. No flashing tools, no bootloader unlocking, no custom recovery, and no permanent modifications to the device. It can even be prepared directly from Android itself using an external SD card reader.
I used Claude, Gemini, and ChatGPT heavily during bring-up for driver debugging, DT syntax, and kernel configuration issues. They accelerated development significantly, but the actual reverse engineering still required hands-on embedded Linux work: boot-chain analysis, DT bindings, panel timings, register experimentation, and kernel panic debugging.
This project also convinced me that modern mobile hardware is massively underutilized once vendor support ends. Many phones and tablets already have hardware comparable to SBCs, but simple external boot support could extend their useful life for homelabs, edge computing, local AI inference, and embedded workloads.
Any feedback, ideas, or contributions are very welcome.
Some time ago I got myself a similarly priced x86-64 Windows tablet on Amazon (Celeron N4020 + 4 GB RAM). I installed Linux Mint on it with a slightly customized kernel (some extra quirks were needed).
I connected an old SSD to it with a SATA2USB adapter, and I use it as a home file server and HTPC. It has a micro HDMI output, and it is connected to my TV. During the day it is playing music non-stop, in the evening it is playing some movies. It has no problem with high bitrate full HD movies, the CPU doesn't even break a sweat. I think it could also play 4K content, if I had any.
(Previously I used a Mac Mini with VLC for this for a few years, but I'm happier with my current setup, it's more stable)
main trouble to me has been caused by unity games - those are the big ram devourers, even most basic 2D ones (I still don't understand how that happens, why such regression since KSP days)
and plenty of 2D games work perfectly fine (devs really overestimate minimal requirements)
If you have decent soldering skills, there are guides online about how you can replace the battery in devices like these by soldering a resistor and a buck converter to the battery pins so it can run permanently without turning the battery into a lithium bomb. If you set up ADB access you can control the screen remotely using scrcpy, all you'd really need is a cheap second hand phone, 20 bucks worth of parts, and a steady hand.
Perhaps Doogee could've ported Android better, but I don't think Android will ever run smoothly on this device.
Android contains a lot of tricks to cache as much as possible in RAM so things like sleep/wakeup and app launching can be very fast. You can see the device take a while to launch a terminal on Debian, that's exactly the kind of thing Android uses all of its RAM for to prevent.
Any familiarity with Safari and blocking performance? uBlock Origin Lite is a simple option, AdGuard can do more (injection?) though uBO feels more trustworthy stillā¦
I completely agree, this is not the place to let AI blindly edit kernel code. The useful approach is to use it conservatively: understand the error, compare against downstream sources, propose a small patch, review it, test it, and then move one step further.
Iād be happy to work together on an article or guidance document, where to start, how to approach debugging, what to never let AI touch blindly, and how to build confidence step by step. That could help others avoid a lot of mistakes and maybe give a second chance to other devices.
Performance is usable, especially compared to stock Android, because there is less background bloat. Itās fine for terminal work, light browsing, VS Code, and small experiments.
If you want you can check my video: https://youtu.be/DbX13_mahKc
as in, I click "open in new tab", some time later I switch to them... only to get hit with "new tab", even though a moment ago it displayed tab name and I could right click -> bookmark to preemptively copy the address
That sounds like an problem Windows could solve.
Generally it's probably just bad optimization. But that only gets you so far because Unity's asset streaming is designed to work with level-based games. It will only let you unload assets if you package them per-level and then swap them in and out at load screens between levels. Absolutely useless for games like KSP.
I prefer spending my time doings I actually want to do. Let the machine do the boring things.
This tickled my imagination and I wondered about a AI assisted reverse engineering platform with a complete build system in which the AI is connected to ports (serial console, gpio, i2c, spi, etc) normal physical switches (on/off, reset, etc) of the target board and a logical switch that can rotate among multiple SD cards either to the development PC and to the board so that the AI itself can download, build in parallel and test images and software freely offloading the most time consuming parts.
Is full 3D acceleration eventually possible and how's battery live?
If people have to buy new PCs, thatās more $$$ for Microsoft.
and yet KSP flies fine, while visual novels crash
Linux can be trimmed way down and with an efficient stack on top can make many devices extremely useable.
Here is a related comment on user software side I made recently.
https://news.ycombinator.com/threads?id=alchemist1e9#4800737...
They're trying to pawn off something with the resolution of the Steam Deck at 10.1 inches running Android with what I would consider the minimum RAM loadout for this device.
The supposed EU-compliant informational brochure I found on a local web store states that the device runs Android 13, so there's a good chance they're either lying about the Android version on eBay or they're faking out the Android version like many Temu phones do.
These devices are useful for two things: to keep kids quiet with a device that can be replaced for not too much money, and now as a means to run Debian on.
I know you just registered to post this, but AI generated comments are not allowed here.
The project looks very cool. Just take the time to write your own comments in your own words and it would certainly be welcomed.
How are you able to boot Debian from an SD card, and without unlocking the bootloader?
Does the bootloader look for an OS on SD card by default? SD and eMMC are basically the same thing, is it just the same lines but an SD card takes priority over the eMMC? And does it not enforce verified boot properly / at all? Maybe being a Rockchip and not MTK/QCOM has something to do with it, but itās still an Android device and I would assume thereās something in CTS/VTS/GMS licensing that makes verified boot mandatory.
Judging from the build.sh, it looks like this is just using unmodified upstream u-boot and tools from the rockchip-linux repository, so "from scratch" is really just analyzing the DTB to see what drivers need to be loaded?
Since I have a desktop I do use rustdesk way more often to just boot into that.
As for PostmarketOS, I've built my own tooling scripts around it to make it easier to build patches, debug hex variables, switch between downstream/mainline and rebuilding everything with a single command. (Unrelased yet though).
I find their tooling okay for a release for end-users but a bit clunky for debugging.
But the answer is fairly simple, on a lot of Rockchip devices Iāve used, if there is no SPI flash or custom boot order, the BootROM checks the SD card first and then falls back to eMMC.
That is what happens here. Take the tablet out of the box, write the image to an SD card, insert it, and it boots directly into Linux instead of Android.
So the eMMC Android bootloader can be locked, but it doesnāt matter much if the SoC boots from SD first. Verified boot applies to the Android boot chain on eMMC, not to an external boot path that is accepted earlier by the Rockchip boot flow.
And now youāll never know if this was an AI answer or not :)
here the hardware is fixed and undocumented. I didnt modify the tablet, I had to figure out what was inside, what could be supported, where to find missing drivers and how to integrate and debug everything until it actually booted and worked.
I am not claiming to be a C or kernel developer. I am just someone hacking around until the device works. Maybe for others this is trivial, but for me it was a very exciting project.
Bookmarks do not store click history, the trajectory you took to arrive at the page. With tabs, the contexts is a backbutton away.
It can still be a bit iffy when memory's really tight, but even then a simple tab reload is usually enough to fix things.
My address is my username @ism.rocks
Alternatively, if you released the article on your blog, I could just follow the RSS feed.
I feel the frustration of reading "slop", but on the other hand the projects that surface do usually bring something useful to the table.
Should we simply judge the submission based on its technical merit? Why do I feel annoyed that an otherwise cool project uses typical LLM prose? For how long will we be able to recognize LLM-generated text, and what happens when we can't?
That's exactly how I'd write it, save for the em dash with spaces around it, which is not how em dashes are normally used in English language.
I think it's an overreaction.
But youāre doing much better than me.
Nothing aside a normal PC. I was the slow human in the middle swapping cards and typing/copying/pasting commands and results; I admit being far away from being able to do that myself; tried a few years ago and failed, then AI happened. The board SoC (Allwinner A20) is already well supported by Linux but there was no image available and the on board hardware wasn't documented, but at least I had a working system to probe the hardware with. The hardest part however was finding the pins used to turn on and off peripherals since reading the Android script.bin and other boot files brought some inconsistencies anyway, so it took long probing sessions. It took weeks before I could have a working video output for example.
Here's an excerpt from a Claude snapshot, probably too long to post entirely (I don't have a GH account, thinking of opening a Codeberg one some day). I later moved everything to Deepseek because Claude became unusable giving just one single prompt before hitting the daily limit; I was about to subscribe to a paid plan but paying users started complaining about shrinking limits as well, so I left.
First came Armbian, then I wanted to have a lighter OS and ported Alpine which boots from a Armbian kernel that then gives control to a full Alpine userland.
Feel free to ask if you need further details. I'm sure the same process could be automated by removing the incredibly slow human and building an interface that would let the AI probe, try and fail, essentially brute forcing unknown hardware until it responds. GIADA NI-A20 - BOARD SNAPSHOT 2026-03-21
=========================================
Board: Giada NI-A20, Nano-ITX form factor
SoC: Allwinner A20 (sun7i) - see snapshot-soc-allwinner-a20.txt
RAM: 1GB
Storage: SD card (primary), NAND (data only), SATA
Serial console: ttyS0 at 115200, RS232 level on DB9 COM2 STATUS:
Armbian: COMPLETE
Alpine: COMPLETE
HARDWARE
--------
SoC: Allwinner A20 (sun7i), dual-core ARM Cortex-A7, ARM Mali-400 MP2
RAM: 1GB
Storage: 8GB NAND (data only, NOT bootable), SD card, SATA
Serial console: ttyS0 at 115200, RS232 level on DB9 COM2
PMU: AXP209 on TWI0 (I2C address 0x34)
RTC: PCF8563 on TWI1 (I2C address 0x51)
Ethernet: GMAC (Gigabit), interface end0
WiFi: AP6210 (Broadcom BCM43362), SDIO on mmc3, 2.4GHz b/g/n
Bluetooth: BCM20710 on uart2 (NOT YET ENABLED in DTS)
GPS: unknown chip, power enable PC22, UART on ttyS1, NMEA at 9600 baud
USB Hub: GL850G on EHCI1, power enable PH7
IR receiver: /dev/lirc0
SATA power connector: JST PH 2.0mm 4-pin (pin1=12V, pin2=5V, pin3=GND, pin4=GND)
LVDS: 30-pin dual channel 8-bit, max 1920x1080
COM2: RS232 Tx/Rx/CTS/RTS 4-wire (DB9 connector)
COM3: RS232 Tx/Rx 2-wire only
VGA: available via J4 14-pin header (non-standard connector)
Mini-PCIe: present, intended for 3G module
SIM card slot: present, for use with 3G module GPIO MAP
--------
PH1 - SD card detect, active LOW
PH4 - USB OTG ID detect
PH5 - USB OTG VBUS detect
PB9 - USB OTG VBUS drive, active LOW
PH6 - USB Host1 VBUS, active HIGH
PH7 - USB Hub power enable (GL850), active HIGH
PH17 - SATA power enable
PH19 - Ethernet PHY power (vcc3v0 regulator), active HIGH
PH25 - USB Host2 VBUS, active HIGH
PI1 - WiFi WL_REGON, active HIGH (mmc3 pwrseq reset gpio)
PI14 - WiFi WL_HOST_WAKE (input)
PI20 - GPS UART7 TX (uart7_pi_pins)
PI21 - GPS UART7 RX (uart7_pi_pins)
PB5 - Bluetooth BT_REGON, active HIGH
PC22 - GPS VCC_EN power enable, active HIGH
PC00-PC16 - NAND bus DTS FIX - MMC3 WIFI PINCTRL
-----------------------------
The mainline A20 DTS was missing pinctrl for mmc3 (WiFi SDIO).
Without it sunxi-mmc driver silently skips mmc3 initialization. Fix applied to:
~/devel/embedded/armbian-build/build/patch/kernel/archive/sunxi-6.12/sun7i-a20-giada-ni-a20.dts
Added to &mmc3 node:
&mmc3 {
pinctrl-names = "default";
pinctrl-0 = <&mmc3_pins>; /\* <-- this line was missing \*/
vmmc-supply = <®_vcc3v3>;
mmc-pwrseq = <&mmc3_pwrseq>;
...
};
DTB recompiled manually (Armbian build used cached version):
cd ~/devel/embedded/armbian-build/build/cache/sources/linux-kernel-worktree/6.12__sunxi__armhf/
sudo touch arch/arm/boot/dts/allwinner/sun7i-a20-giada-ni-a20.dts
sudo make ARCH=arm allwinner/sun7i-a20-giada-ni-a20.dtb
CRITICAL: DTB lives in /boot/dtb/ not /boot/ on this board.
U-Boot boot.cmd looks in ${prefix}dtb/ directory.
Correct location: /boot/dtb/sun7i-a20-giada-ni-a20.dtb WIFI - AP6210 (BCM43362)
-------------------------
Chip: Broadcom BCM43362, SDIO on mmc3, 2.4GHz b/g/n only
Driver: brcmfmac + pwrseq_simple
Firmware: brcmfmac43362-sdio.bin + brcmfmac43362-sdio.txt
Location: /lib/firmware/brcm/
Board-specific symlinks (created by build-image.sh):
brcmfmac43362-sdio.giada,ni-a20.bin -> brcmfmac43362-sdio.bin
brcmfmac43362-sdio.giada,ni-a20.txt -> brcmfmac43362-sdio.txt No CLM blob available for BCM43362 (chip predates CLM blob requirement).
Result: limited to channels 1-11, TX power 31dBm.
The driver logs "no clm_blob available" - this is normal, not an error. P2P error at init is harmless - BCM43362 does not support P2P mode.
WIFI BOOT SEQUENCE:
1. eudev starts at sysinit runlevel
2. pwrseq_simple loads from /etc/modules
3. mmc1 (SDIO) initializes, BCM43362 detected
4. brcmfmac loads from /etc/modules
5. eudev firmware rule instantly rejects missing clm_blob (no 60s timeout)
6. wlan0 appears, wifi OpenRC service starts wpa_supplicant
7. dhcpcd obtains IP on wlan0
eudev firmware rule (/etc/udev/rules.d/50-firmware.rules):
SUBSYSTEM=="firmware", ACTION=="add", \
TEST!="/lib/firmware/$env{FIRMWARE}", ATTR{loading}="-1"
Purpose: instantly rejects missing firmware requests instead of waiting
60 seconds per file for a userspace agent that never comes.
Without this rule: 120s boot delay (2x 60s timeouts for clm_blob + txcap_blob)
With this rule: WiFi up in ~15 secondsFor Wi-Fi, I even contacted the chip factory. They didnāt answer at first, so I wrote again in Chinese with AIās help and eventually got the drivers.
We are not yet at the point where you give AI a tablet and it magically returns a working image. AI helped a lot, but it also introduced bugs more than once. The real work was still testing, breaking things, fixing them, and repeating.
I posted it here because I think the project is useful and could attract people who want to build on it. All the devices should be more open, repairable, and reusable, so we can actually own the hardware we buy.
The people who donāt even take 30 seconds to write their own comments arenāt here to share their knowledge or discuss the project. Itās self-advertising. They might be following instructions from the LLM to post it here. There was a project a couple days ago that still had the AI-generated marketing plan in git which instructed the person to post it here and then on some subreddits, including marketing copy to include.
The projects often donāt work, too. Remember the guy who claimed to have uncovered a multi billion dollar Meta influence campaign? When I read the documents they had output from Claude saying that it failed to access the documents, but then it guessed what the document might include. The whole report was full of this, but it was posted here and upvoted as if someone had done deep research.
Claude was definitely helpful the second time around to help with the DTS.
I think surrounding it with spaces comes from people using a regular dash (the em dash is not readily accessible on the keyboard), then surrounding it with spaces to make sure itās not interpreted as a dash.
Would like to try this out, but getting an incompatible machine would be a real bummer.
Edit: OK, I think the Android 15 is this one: https://www.amazon.de/-/en/DOOGEE-U10-Tablet-WiFi-128GB/dp/B... (Nov/Dec delivery)
Very much not the case with the comment I responded to.
There is a stark contrast between the AI written first comment and some of their other comments.
I know many here donāt like any accusations of AI writing because they arenāt as attuned to picking it up, but the comment I responded to was as blatant as it gets.
I tried to give a more friendly encouragement to share self-written comments.
I've read a few typography related books and checked some style manuals in my time, but no-one has ever 'corrected' my usage so I think it's alright.
I was listening to a podcast recently that had interesting information about the birth of mdash - "99% Invisible: The Em Dash".
Episode webpage: https://99percentinvisible.org/?p=46542. (Antenna Pod is a great podcast player!)
On the units I tested, the board says: RK3562-v1.0 2024.06.28.
This is the listing I used, but it is currently out of stock:
I don't have anything to add. It just seems like you misunderstood my message.
Current public build (pre-release, May 14, 2026):
- Release page: tech4bot/rk3562deb prerelease-14052026
- Direct image download: rk3562-debian.img.xz
- Video demo: YouTube
Run full Debian 12 Bookworm on your Doogee U10 tablet ā no bootloader unlock required. Boot from SD card, remove it to return to stock Android. No changes to internal storage.
Reverse engineered from scratch ā no BSP, no vendor documentation, no official support. Built with the help of Claude, Codex, and Antigravity (Google Gemini), using Firefly RK3562 open-source repositories as a starting point.
rkdebian is a build system that produces a complete, bootable Debian 12 Bookworm image for the Doogee U10 Android tablet, powered by the Rockchip RK3562 SoC.
The resulting image is written to an SD card. Insert it and power on ā the tablet boots Debian. Remove the SD card and it boots Android from internal eMMC as normal.
| Component | Details |
|---|---|
| SoC | Rockchip RK3562 (4Ć Cortex-A53 @ 2.0 GHz) |
| NPU | 1Ć Rockchip NPU core (active for RKLLM inference) |
| RAM | 4 GB LPDDR4 |
| Storage | 128 GB eMMC (Android) + SD card (Debian) |
| Display | 10.1" DSI panel, 1280Ć800 |
| PMIC | RK817 |
| Feature | Status |
|---|---|
| Display / Panel | ā Full |
| Touchscreen | ā Full (gsl3673, 10-point multitouch) |
| Wi-Fi | ā Full (Seekwave EA6621Q) |
| Bluetooth | ā Full |
| Speaker / Audio output | ā Full |
| Microphone | ā Full |
| 3D Acceleration | ā ļø Partial (Panfrost, OpenGL ES works) |
| NPU (RKLLM / rknn-llm) | ā
Active (RK3562 supports one NPU core, num_npu_core=1) |
| Accelerometer | ā Full (SC7A20 / DA223) |
| Flashlight (rear LED) | ā
Full (native Phosh top-menu torch toggle + brightness control via rk-flashlightctl) |
| Power button behavior | ā Full (short press sleeps on release, long press >=3s opens shutdown dialog) |
| Lockscreen orientation memory | ā Full (lock screen keeps last tablet orientation, including landscape) |
| Cameras | ā ļø Partial (front s5k5e8 + rear s5k4h5yb pipelines functional; color tuning still needs calibration) |
| Battery / Charging | ā Full (RK817 PMIC) |
| SD card boot | ā Full |
| USB OTG | ā Full |
| App | Notes |
|---|---|
| Firefox ESR | Preinstalled web browser |
| Chromium | Preinstalled web browser (installed when available on mirror) |
| FreeTube | Installed via Flatpak from Flathub by default (disable with RKDEBIAN_PREINSTALL_FREETUBE=0 for smaller images) |
| Drawing | Touch-friendly paint app (installed when available on mirror) |
| Snapshot | Camera app (installed when available on mirror) |
| Dolphin | File manager |
| Plasma Discover | App store / software center |
| Okular | Document/PDF viewer |
| Gedit | Text editor |
| Pavucontrol | Audio controls |
| Terminal | kgx preferred, gnome-terminal fallback |
| Flatpak + Flathub | Enabled by default for app installs |
This tablet image supports local LLM inference on the RK3562 NPU using Rockchip's RKLLM stack.
llm_demo)rk3562W8A8num_npu_core=1 (RK3562 supports one NPU core)0 (chosen for compatibility/stability on this board)Example conversion command (host PC):
python3 convert_qwen_rk3562.py \
--model-dir ./models/Qwen3-0.6B \
--target-platform rk3562 \
--quantized-dtype W8A8 \
--optimization-level 0 \
--num-npu-core 1 \
--output ./out/Qwen3-0.6B_W8A8_RK3562_opt0.rkllm
Measured on April 6, 2026 on <tablet-ip> with:
Output exactly 300 English words about arithmetic speed testing do not include punctuation and do not stop earlyMAX_NEW_TOKENS=64, MAX_CONTEXT_LEN=1024~/npu-test/xcompile/demo_Linux_aarch64/run_llm_rk3562.shCommands used:
# Qwen3-0.6B (first run includes fix_freq)
USE_FIX_FREQ=1 RKLLM_LOG_LEVEL=1 PROMPT="Output exactly 300 English words about arithmetic speed testing do not include punctuation and do not stop early" \
./run_llm_rk3562.sh ~/npu-test/models/Qwen3-0.6B_W8A8_RK3562_opt0.rkllm 64 1024
# Qwen2.5-1.5B
USE_FIX_FREQ=0 RKLLM_LOG_LEVEL=1 PROMPT="Output exactly 300 English words about arithmetic speed testing do not include punctuation and do not stop early" \
./run_llm_rk3562.sh ~/npu-test/models/Qwen2.5-1.5B-Instruct_W8A8_RK3562.rkllm 64 1024
Warm-run average (runs 2-3):
| Model | Init Time (ms) | Prefill (tok/s) | Generate (tok/s) |
|---|---|---|---|
Qwen3-0.6B_W8A8_RK3562_opt0 |
1788.70 |
57.62 |
4.92 |
Qwen2.5-1.5B-Instruct_W8A8_RK3562 |
4800.76 |
42.78 |
2.18 |
Result: Qwen3-0.6B is significantly faster on this RK3562 tablet for local NPU inference.
0% after the tablet has been powered off for a couple of hours.rk-battery-gauge-fix.service fixes this on boot.s5k5e8) and rear (s5k4h5yb) camera preview/capture are functional, but colors are still slightly off and require additional ISP calibration.Host machine: x86-64 Linux (Debian/Ubuntu recommended)
Install all build dependencies with:
sudo apt-get install \
git make gcc-aarch64-linux-gnu \
bc bison flex device-tree-compiler \
genimage wget tar mtools \
xz-utils \
debootstrap qemu-user-static \
e2fsprogs
Builds U-Boot, kernel, Debian rootfs, and produces a ready-to-flash SD card image:
./build.sh all
With full logging to file (tee) while preserving the real build exit status:
set -o pipefail
./build.sh all 2>&1 | tee build.log
./build.sh with no target defaults to all.
The final image is written to:
out/rk3562-debian.img.xz ā compressed final image (recommended)output/update/update.img.xz ā compressed Firefly-compatible pathCompatibility/raw images are also kept:
out/rk3562-debian.imgoutput/update/update.img./build.sh [options] {check|lunch|uboot|extboot|updateimg|updatepkg|compile|rootfs|image|all}
| Option | Values | Description |
|---|---|---|
--ui-session |
phosh |
Session profile to bake into the image |
--gpu-stack |
mali, panfrost |
Select userspace/kernel graphics stack |
--display-server |
auto, wayland, x11 |
Desktop backend preference passed into rootfs build |
--cpu-governor |
e.g. performance, schedutil |
Baseline governor used by power-tuning services |
--force-clean-rootfs |
flag | Force full rootfs rebuild (same effect as RKDEBIAN_FORCE_CLEAN_ROOTFS=1) |
--no-force-clean-rootfs |
flag | Explicitly disable forced rootfs cleanup |
-h, --help |
flag | Show usage |
| Command | What it does |
|---|---|
./build.sh check |
Verify all build dependencies are installed |
./build.sh lunch |
Select a build configuration (defconfig) |
./build.sh uboot |
Build U-Boot only |
./build.sh extboot |
Build the Linux kernel only |
./build.sh rootfs |
Build the Debian 12 rootfs only, then verify the requested build profile marker |
./build.sh compile |
Build U-Boot + kernel (skip rootfs and image) |
./build.sh image |
Assemble the final SD card image from existing artifacts (with rootfs profile verification) |
./build.sh updateimg |
Legacy image assembly path (SDK-compat); packages image without running profile verification |
./build.sh updatepkg |
Create an offline update tarball (output/update/update.tar.gz) from out/rootfs + out/boot/* |
./build.sh all |
Full end-to-end build (default) |
image and updatepkg require existing build artifacts (out/rootfs, kernel/DTB, and boot config files).
These variables can be set before running build.sh to control build behaviour:
| Variable | Default | Description |
|---|---|---|
RKDEBIAN_FORCE_CLEAN_ROOTFS |
0 |
Set to 1 to wipe and fully rebuild the Debian rootfs from scratch. Useful when switching between different image profiles so stale packages do not carry over. |
ROOTFS_IMAGE_SIZE |
auto |
Override the rootfs partition size (e.g. 4G, 3584M). By default the size is calculated automatically from actual rootfs usage plus headroom. |
ROOTFS_HEADROOM_MB |
512 |
Free space headroom added on top of actual rootfs usage when using auto sizing. |
ROOTFS_MIN_MB |
2560 |
Minimum rootfs image size in MiB when using auto sizing. |
RKDEBIAN_DISPLAY_SERVER |
wayland |
Session backend preference for desktop stack selection (wayland, x11, or auto). Phosh images use Wayland by default. |
RKDEBIAN_UI_SESSION |
phosh |
UI session to auto-login in LightDM. Current supported value: phosh. |
RKDEBIAN_GPU_STACK |
mali |
GPU stack to build for: mali (vendor userspace) or panfrost (Mesa/Panfrost, no libmali). |
RKDEBIAN_CPU_GOVERNOR |
performance |
Baseline CPU governor used at boot and as the default mapping for Phosh balanced mode. |
RKDEBIAN_MALI_GBM_PROVIDER |
vendor |
Mali-only option: vendor keeps mali/libgbm.so.1 from the blob package (default), debian overrides it to Debian libgbm.so.1 for compatibility testing. |
RKDEBIAN_PREINSTALL_FREETUBE |
1 |
Set to 0 to skip FreeTube preinstall and significantly reduce image size. |
RKDEBIAN_MINIMIZE_IMAGE |
0 |
Set to 1 for aggressive size reduction (prunes non-English locales plus /usr/share/doc, /usr/share/help, /usr/share/man, /usr/share/info, and unused Flatpak objects). |
| Variable | Default | Description |
|---|---|---|
RKDEBIAN_MAKE_THREADS |
auto |
Override kernel build parallelism. By default it uses a memory-safe value (min(nproc, RAM_GiB/2)) to reduce random cc1/drivers build failures on low-RAM hosts. |
RKDEBIAN_KEEP_OVERLAY_PMIC_PATCHES |
0 |
Set to 1 to use the overlay PMIC drivers (rk808.c, rk817_battery.c, rk817_charger.c) instead of the upstream kernel versions. |
# Force a clean rootfs rebuild
RKDEBIAN_FORCE_CLEAN_ROOTFS=1 ./build.sh all
# Same using CLI flags
./build.sh all --force-clean-rootfs
# Force clean rootfs rebuild with a fixed 4 GB rootfs partition
RKDEBIAN_FORCE_CLEAN_ROOTFS=1 ROOTFS_IMAGE_SIZE=4G ./build.sh all
# Build only the rootfs, force clean
RKDEBIAN_FORCE_CLEAN_ROOTFS=1 ./build.sh rootfs
# Rebuild image only (U-Boot and kernel already built)
./build.sh image
# Build kernel only
./build.sh extboot
# Keep overlay PMIC patches during kernel build
RKDEBIAN_KEEP_OVERLAY_PMIC_PATCHES=1 ./build.sh extboot
# Force a Wayland desktop image for testing
./build.sh all --display-server=wayland
# Explicitly disable force-clean (useful in scripted runs)
./build.sh all --no-force-clean-rootfs
# Override baseline governor used for Phosh balanced mode mapping
RKDEBIAN_CPU_GOVERNOR=schedutil ./build.sh all
# Show CLI usage and target list
./build.sh --help
# Build a Phosh image on Mesa/Panfrost (clean rootfs strongly advised)
./build.sh all --ui-session=phosh --gpu-stack=panfrost --force-clean-rootfs
# Mali stack with Debian libgbm override (only for compatibility testing)
RKDEBIAN_MALI_GBM_PROVIDER=debian ./build.sh all --ui-session=phosh --gpu-stack=mali --force-clean-rootfs
# Size-focused build for easier GitHub uploads
RKDEBIAN_FORCE_CLEAN_ROOTFS=1 RKDEBIAN_MINIMIZE_IMAGE=1 RKDEBIAN_PREINSTALL_FREETUBE=0 ./build.sh all
# Size-focused build while keeping default FreeTube preinstall enabled
RKDEBIAN_FORCE_CLEAN_ROOTFS=1 RKDEBIAN_MINIMIZE_IMAGE=1 RKDEBIAN_PREINSTALL_FREETUBE=1 ./build.sh all
When changing RKDEBIAN_UI_SESSION or RKDEBIAN_GPU_STACK, use --force-clean-rootfs to avoid stale package carry-over.
Images include rk-power-profile-sync.service, which maps Phosh power modes
(power-profiles-daemon) to cpufreq policy on-device:
balanced -> governor from RKDEBIAN_CPU_GOVERNOR (default performance), max freq cap 100%power-saver -> governor powersave, max freq cap 65%performance (if exposed by hardware) -> governor performance, max freq cap 100%Tune mapping on-device in /etc/default/rk-power-profile-map.
camera:flash, so Phosh shows the native top-menu torch icon.rk-flashlightctl supports both toggle and intensity control (set 0..100) for the rear LED.rk-powerkey-longpress.service owns hardware power-key policy:<3s) -> suspend on key release>=3s) -> standard GNOME shutdown dialogImages include rk-session-failsafe.timer, which checks 5 minutes after boot if a risky session test is still armed.
# Arm rollback before rebooting into a risky session test
sudo install -d /var/lib/rk-session-failsafe
sudo touch /var/lib/rk-session-failsafe/armed
sudo reboot
Behavior:
Once the tablet is running Debian, you can apply updates without reflashing the SD card.
Build an update package on your host:
./build.sh all # or just ./build.sh image && ./build.sh updatepkg
This produces output/update/update.tar.gz.
Copy it to the tablet (via USB, SSH, or any file manager) and drop it in one of these inbox directories:
| Path | Notes |
|---|---|
/home/chaos/update/ |
Primary drop location |
/update/pending/ |
Alternative drop location |
On the next reboot, the rk-apply-update service automatically detects the newest *.tar.gz or *.tgz package, applies rootfs + boot payloads, then reboots to finalize. Legacy compatibility path /update/update.tar.gz is also checked.
Package archive behavior:
/update/applied//update/failed//update/duplicate/Update progress and errors are logged to /var/log/rk-update.log.
If a package fails to apply (corrupt archive, wrong layout) it is moved to
/update/failed/and the system boots normally.
After a successful build, flash the compressed image to your SD card:
# Replace /dev/sdX with your SD card device (check with lsblk)
xz -dc out/rk3562-debian.img.xz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync
Warning: Double-check the device path. Writing to the wrong device will overwrite your data.
Insert the SD card into the Doogee U10 and power it on. Debian will boot automatically. Remove the SD card to return to Android.
The build system creates the following accounts in the Debian image:
| Account | Username | Password | Notes |
|---|---|---|---|
| Standard user | chaos |
chaos |
Passwordless sudo |
| Root | root |
root |
Direct root login |
Change these on first boot:
passwd # change chaos password sudo passwd root # change root password
The SD card image uses a GPT partition table:
| Partition | Offset | Size | Contents |
|---|---|---|---|
idbloader |
32 KiB | ā | SPL / first-stage bootloader |
uboot |
8 MiB | ā | U-Boot FIT image |
boot |
16 MiB | 256 MiB | FAT: kernel Image, DTB, extlinux.conf |
rootfs |
272 MiB | auto | ext4: Debian 12 Bookworm root filesystem |
The rootfs partition is automatically expanded to fill the SD card on first boot.
rkdebian/
āāā build.sh # Main build entry point
āāā build_rootfs.sh # Debian rootfs builder (debootstrap + chroot)
āāā genimage.cfg # SD card image partition layout
āāā extlinux.conf # Bootloader config (kernel + DTB)
āāā splash.png # Boot splash screen
āāā overlay/ # Custom kernel drivers, DTS, firmware, services, and headers
ā āāā arch/ # Device tree sources (DTS/DTSI)
ā āāā drivers/ # Out-of-tree kernel drivers (Wi-Fi EA6621Q, cameras, PMIC)
ā āāā firmware/ # Wi-Fi firmware blobs (Seekwave EA6621Q)
ā āāā include/ # Build-time kernel header overrides
ā āāā kernel-patches/ # Kernel patches applied during build
ā āāā etc/ # On-device config overrides (logind, etc.)
ā āāā mali-shim.c # Mali GPU userspace shim (compiled during build)
ā āāā *.sh / *.service # On-device setup scripts and systemd units
āāā debs/ # Pre-built .deb packages (Mali GPU, Rockchip MPP)
āāā mali/ # Mali GPU userspace library (.so)
āāā wifi/ # Wi-Fi firmware, vendor SDK, and porting guides
āāā tools/ # On-device camera capture and ISP diagnostic tools
āāā docs/ # Design specs and build notes
āāā src/ # Cloned sources (kernel, u-boot, rkbin) ā populated by build
āāā out/ # Build artifacts (kernel, rootfs, images)
āāā output/update/ # Final flashable image + OTA update package
| Component | Version / Branch |
|---|---|
| Linux kernel | 6.1.x (develop-6.1, rockchip-linux) |
| U-Boot | Firefly rk356x/firefly-5.10 |
| rkbin | Rockchip upstream master |
| Debian | 12 Bookworm (arm64) |
Third-party components included in this repository:
The prebuilt Mali GPU packages in debs/ and the userspace library in mali/ are sourced from:
These binaries are provided by those projects under their respective terms. ARM Mali firmware and userspace libraries are proprietary ARM IP.
The Rockchip MPP packages in debs/ (librockchip-mpp1, librockchip-mpp-dev, librockchip-vpu0) are sourced from:
Rockchip MPP is licensed under the Apache 2.0 License.
The Wi-Fi and Bluetooth driver source in overlay/drivers/net/wireless/ea6621q/ and firmware blobs in overlay/firmware/ and wifi/ are provided by Seekwave Technology Co. Ltd. The driver is released by the vendor under the GNU General Public License v2.0 (GPL-2.0).
MIT License ā Ā© 2026 tech4bot
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
The Linux kernel, U-Boot, Debian packages, Rockchip rkbin, and third-party drivers included in or produced by this build system retain their respective upstream licenses.