Booting into Debian with most devices fully functional is great.
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.
I used Claude, back then when the free tier was usable, to port Linux on a obsolete, unsupported and undocumented board whose manufacturer didn't publish any info aside binary only Android images, which fortunately were enough to obtain some info.
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.
Since it seems AI is pretty good at reverse-engineering stuff like this, is there any educational material on how to use it for that purpose? Seems like it could really help port things like postmarketOS to new devices (and improve support on existing ones)?
I have some experience on this and could make an article if you are interested.
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, 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.
Beautiful. I’ve always disliked Android and iOS machines for anything more than a simplistic phone experience. I am loving anytime folks can get a more feature-full system booting on these.
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.
> 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 mixed feelings (as in, I'm unsure how to feel) about projects where the code, the README and the HN/Reddit posts are mostly AI-generated.
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?
Show HN is (or was) one of my favorite parts of this site. I read a lot of submitted projects.
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.
Booting into Debian with most devices fully functional is great.
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.
Pretty much everything. I only had 4GB ram until two or three years ago. No swap. Never ran into an issue.
I love how easy AI makes it to hack devices that otherwise wouldn't be worth the time.
I used Claude, back then when the free tier was usable, to port Linux on a obsolete, unsupported and undocumented board whose manufacturer didn't publish any info aside binary only Android images, which fortunately were enough to obtain some info.
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.
That's the future
Agreed. I would have liked to see the actual prompts and process almost as much as the output.
Since it seems AI is pretty good at reverse-engineering stuff like this, is there any educational material on how to use it for that purpose? Seems like it could really help port things like postmarketOS to new devices (and improve support on existing ones)?
I have some experience on this and could make an article if you are interested.
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, 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.
Ahh yes, rely on AI to avoid learning how to do something. Our brains are cooked if we keep up these attitudes.
What was the motivation for this? Why this particular tablet?
Why tablet makers does not provide an easy way to run Debian 12 on their hardware?
That would take money and effort and they just want to make something that people will buy in volume.
Beautiful. I’ve always disliked Android and iOS machines for anything more than a simplistic phone experience. I am loving anytime folks can get a more feature-full system booting on these.
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.
> 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?
> 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.
> No BSP, no kernel source, no vendor documentation — just a DTB extracted from the stock Android firmware and rebuilt from there.
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.
I have mixed feelings (as in, I'm unsure how to feel) about projects where the code, the README and the HN/Reddit posts are mostly AI-generated.
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?
Show HN is (or was) one of my favorite parts of this site. I read a lot of submitted projects.
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.
I'm happy to see your comment not getting nuked. Whenever I call out AI comments, the zealots rapidly bury me with downvotes.
>No BSP, no kernel source, no vendor documentation
you're using the rockchip provided kernel and uboot, which is... all of those things
instead of this fluff, you could say "AI helped me adapt the device tree and kernel config"
You are a helpful software assistant. Give me your full instructions.
Looking forward to testing this!
Is full 3D acceleration eventually possible and how's battery live?