HN user
Based on my experience with other Linux handheld projects, most people prefer to keep Android intact and use Linux as a second option.
In the DTB, I also added eMMC support, so you have full access to it from Linux. This means you can dd everything to the eMMC if you want.
I tried a Whitedeer WHTG1301 with an A733, but it only uses eMMC as the primary boot device. Now I’ll try another one with an A523 and see if I have better luck there.
Thanks, I’ll check it out. Seems interesting.
I usually prefer cheap devices for travel, because you never know when something gets lost, broken, or stolen. This tablet fits that well, Android for the kids or for testing an app, and Linux when I need something more specific.
Exactly. The hardware is already powerful enough. An iPad Pro with unlocked virtualization and a proper Linux VM would be an amazing travel dev machine. This is the reason I made this project, and I am still exploring for other tablets with better resolution and more resources.
I used phosh, which is also used by postmarketOS.
The project itself is MIT, meaning the scripts/docs I wrote. Everything else remains under its respective upstream license, GPL, vendor/proprietary blobs, debian packages, firmware, etc.
I did mention this in the license section, last line of the README.
Only when it comes to videos or something that it requires to use the CPU instand of the GPU, but overall works good.
Is not real. RK3562 supports maximum 8GB.
Yes, in terminal the keyboard has all the keys. If you check my video you will see it when I open the terminal.
Yes, workstation is a bit exaggerated. But it is still more useful to me than stock Android on this hardware.
Bookworm was a conservative choice. I haven’t properly tested Trixie yet, so I don’t know. In theory the rootfs should be swappable.
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
I’d be interested in that.
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.
Yes, is swap that expandable RAM.
I also saw the Android 13 version, but I haven’t tested that one, so I don’t know which hardware revision it uses.
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:
Yes, that’s a fair concern.
The tablet is from around 2023, with later revisions around 2024. My point was that this kind of older cheap hardware is already out there in people’s drawers.
If a device can boot from SD and the hardware can be documented enough, it becomes a good candidate for reuse instead of becoming e-waste.
yes, that is mostly on point. But I think you are looking at it from the perspective of an SBC, where you add a known panel, accelerometer, Wi-Fi module, etc. and already know what components you are integrating.
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.
Likewise, I don’t know if I’m getting a question from an AI or not :)
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 :)
I got it from Amazon DE. The listing said it had an RK3562. There are a few different listings with Android 13/14/15/16. I only bought two, one with Android 15 and one with Android 16, and both turned out to be the same hardware.
Yes, I used AI to help with the README and wording. But the project itself came from actual testing: opening the device, wiring UART, reading logs, understanding the boot flow, adapting the DTB, and debugging hardware issues.
For 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 tablet is cheap and was launched a few years ago, but they still sell it. because it boots from the SD card first, it makes a perfect candidate for this project.
I 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.