31–40 of 53 posts
> In mainline linux, XIP support on RISC-V was removed, so 6.12 was used instead which has proper XIP support. Doesn't that put it in an awkward position relying on a dead end feature?
What I remember was they said it could come back if people needed it but it was broken for looking (months, years) at a time. So even if they didn't remove it, 6.12 might be the last working version with it anyway
Earlier quoted context omitted.
It takes no effort to play LLM or not, you don't need to know anything about the topic or put anytime into reading and understanding the submission, just find that em-dash and you can turn every discussion into meta slop.
I also think an LLM isn't going to just spit this all out and viola, it boots. I imagine there were many rounds of jtag debug, copy/paste into the LLM prompt, with enough human knowledge/context to say the right thing, suggest some existing implementation snippet, etc.
You may not be familiar with modern LLM tools.
You don’t need to copy/paste anything. You can easily instruct your agent to access the serial port and JTAG debugger and it will easily handle it through subsessions.
The tools have moved rapidly this year. Something like this is entirely doable by attaching the right cables, telling the agent where to access everything, and then keeping it fed with enough tokens to keep going.
There are some amazing projects doing reverse engineering or porting to micros fully automated. The results are still full of typical LLM output problems, but it’s amazing what can be brute forced with enough tokens in an LLM loop.
When I’m evaluating MCU platforms for new projects I’ll some times set an LLM loose on each to get a proof of concept running so I can do benchmarks or testing. It can save a lot of time finding showstoppers or roadblocks before I waste a lot of time on doing the problem correctly.
Obviously vibecoded but interesting nevertheless. The agent left everything marked as untested in the README but the output snippets toward the bottom imply that it got something working enough to log in and run some commands. Nobody is going to mistake this for a carefully crafted port of Linux but it at least serves as a proof of concept. The real downside of the vibecoding is that we don’t get any helpful informat…
Given the context of a vibe-coded project, would it be reasonable to assume the example outputs are outright hallucinations, without seeing indisputable evidence to the contrary? Sad that’s where my mind goes, but this is what the world has been training me to believe. And these doubts now eclipse the skepticism that I developed toward things that humans posted on the internet. Lies, damn lies, and LLMs.
I also think it’s pretty cool.
We do need to keep it in context though.
Earlier quoted context omitted.
The news is: vibe coder vibe coded this and got their agents to upvote it.
For a worthy goal .. linux on esp would be a game changer for iot imho
(Worthy goal though I agree there. Fun at the minimum.)
The derisive "vibe-coded" label is one thing, but the least compelling argument or complaint of them all is the truly worn out one about barriers to entry that you and I and so many others worked soooo hard to climb over are now being obliterated, allowing any casual Moe to stroll into your domain. How many professionals -- djs, photographers ... hell, SEO experts -- pretty much anyone technical and possibly creative have watched technology make work and the accumulation of competitors almost too easy.
If you just remember that no one in this time-space or anyother AFAICT is forcing you to consume or even read about projects like this, you'll find life goes on and you're actually still an expert who people who need experts will value materially (which should be your thing, otherwise wth are you complaining about?)
In fact, if you keep your mind open you might -- not definitely but _just_ _might_ -- find a piece of something useful amidst the slop. One fellow's trash ...
How can it run when there is no MMU? Isn't this like rewriting a large part of the kernel?
There is actually precedent for nommu Linux, though it obviously has tradeoffs.
Seeing the title of this submission reminded me of it because I messed around with it a bit a few years ago.
When can we run doom on it?
There have been esp32 ports of doom for a decade though. Here's a current one: https://github.com/AmirhoseinMasoumi/ESP32-DOOM
It's not nearly impossible, it has already been done :)
Slides: https://fahrplan.events.ccc.de/congress/2024/fahrplan/media/...
- Yes it is vibe coded. It do work on real S31 dev boards (there's console output and binary releases to prove that.) I understand the esp32 microcontroller architecture to some extent, but I barely know how to port Linux to other RISC-V platforms; what I did is to tell the agent something like "Go implement an IPC transport that uses a shared SRAM buffer and an IPC interrupt doorbell" or "sdmmc uses designware ip; search esp-idf usage and port the existing Linux driver over." An AI agent on its own would never discover S31's bespoke hardware behavior without my guidance, for example, that the register `mcliccfg` has writable bits, despite esp-idf saying otherwise. However I admit that AI assistance is the direct reason why I am able to progress this fast, and I did learn a lot about kernel development during the process. If you're bothered by AI code, move on.
- Untested is a bit misleading: per the README, means "seems working; not thoroughly tested." They do seem to work at the time when their drivers are being built. Three weeks into this project I can't have everything stress-tested already.
- I built this more as a proof of concept intending for my own use; I did not expect it to gain popularity anytime soon, so the docs are very bad for now.