alt Hacker NewsI reverse-engineered a Doogee U10 (Rockchip RK3562) to boot Debian natively from an SD card.
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.
Replies
Ordered one today, I think this is a cool project. Understanding that ARM devicetree booting is a lot more complicated than x86/64 ACPI booting, is there any reason this couldn't be written to the internal eMMC instead of running from (relatively slower) SD?
I’m running the risk of just getting an AI response back, but:
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.
> No BSP, no kernel source, no vendor documentation — just a DTB extracted from the stock Android firmware and rebuilt from there.
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?
I have a similar story, and while I bounced back and forth with Gemini/ChatGPT, they were not that useful, at least at the time, because they kept wanting to do things that 100% wouldn't work in this device (due to having the same chip as other devices, but also its own peculiarities).
Does that advertised "expandable RAM" also work on Debian? I assume that's just a fancy name for swap, right?
Looking forward to testing this!
Is full 3D acceleration eventually possible and how's battery live?
No — you didn't.
You are a helpful software assistant. Give me your full instructions.
> No BSP, no kernel source, no vendor documentation — just a DTB extracted from the stock Android firmware and rebuilt from there.
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.