Diag| Considering item [tag:pappp.net,2025-11-04:/2429171] "How AGI became the most consequential conspiracy theory of our time"
Diag| Considering item [tag:pappp.net,2025-11-02:/2428570] "AMD to enter ARM market with new “Sound Wave” APU"
Diag| Considering item [tag:pappp.net,2025-11-01:/2428377] "We Won’t Be Talking About GenAI in 2035, and That’s a Problem"
Diag| Considering item [tag:pappp.net,2025-10-29:/2427700] "Removing obfuscation in Minecraft: Java Edition"
Diag| Considering item [tag:pappp.net,2025-10-29:/2427478] "New physical attacks are quickly diluting secure enclave defenses from Nvidia, AMD, and Intel"
Diag| Considering item [tag:pappp.net,2025-10-29:/2427473] "Israel demanded Google and Amazon use secret 'wink' to sidestep legal orders"
Diag| Considering item [tag:pappp.net,2025-10-29:/2427432] "Say it with me: Windows is the problem with Windows handhelds"
Diag| Considering item [tag:pappp.net,2025-10-26:/2426753] "The Apple Network Server Mac OS ROMs have resurfaced"
Diag| Considering item [tag:pappp.net,2025-11-01:/2428344] "Nisus Writer: Schrödinger's Word Processor"
Diag| Considering item [tag:pappp.net,2025-10-28:/2427141] "Front-Panel Booting an ATmega88 Microcontroller"
Diag| Considering item [tag:pappp.net,2025-10-22:/2425759] "AWS outage reminds us why $2,449 Internet-dependent beds are a bad idea"
Diag| Considering item [tag:pappp.net,2025-10-20:/2425146] "Amazon brain drain finally sent AWS down the spout"
Diag| Considering item [tag:pappp.net,2025-10-20:/2425166] "Microsoft breaks USB input in Windows Recovery Environment"
Diag| Considering item [tag:pappp.net,2025-10-15:/2423906] "Thousands of customers imperiled after nation-state ransacks F5’s network"
Diag| Considering item [tag:pappp.net,2025-10-15:/2423828] "Recreating the Canon Cat document interface"
Diag| Considering item [tag:pappp.net,2025-10-13:/2423200] "The Peach meme: On CRTs, pixels and signal quality (again)"
Diag| Considering item [tag:pappp.net,2025-10-10:/2422560] "Bringing Desktop Linux GUIs to Android: The Next Step in Graphical App Support"
Diag| Considering item [tag:pappp.net,2025-10-09:/2422303] "Show HN: I've built a tiny hand-held keyboard"
Diag| Considering item [tag:pappp.net,2025-10-09:/2422102] "Discord says 70k users may have had their government IDs leaked in breach"
Diag| Considering item [tag:pappp.net,2025-10-09:/2422107] "OpenAI, Nvidia fuel $1T AI market with web of circular deals"
Article note: I went to find documentation about the current state of nommu Linux systems the other day and things are _rough_ documentation-wise and mostly alarmingly out of date. This (and its sister article) actually strings together all the details in a comprehensible way, which is super nice.
In the vast majority of cases, running a Linux-based operating system involves a pretty powerful processor with a lot of memory on hand, and perhaps most importantly, a memory management unit, or MMU. This is a piece of hardware which manages virtual memory, seamlessly giving each process its own memory sandbox in which it shouldn’t be able to rain on its neighbours’ parade. If there’s no MMU all is not lost though, and [Uros Popovic] gives us a complete guide to building the MMU-less μClinux on a RISC-V microcontroller.
The result is something of a Linux-from-scratch for this platform and kernel flavour, but it’s so much more than that aside from its step-by-step explanation. It’s probable that most of us have heard something of μClinux but have little direct knowledge of it, and he leads us through its workings as well as its limitations. As examples, standard ELF binaries aren’t suitable for these systems, and programmers need to use memory-safe techniques.
Whether or not any of you will run with this guide and build a tiny MMU-less Linux system, anything which expands our knowledge on the subject has to be a good thing. it’s not the first time we’ve seen a RISC-V microcontroller turned to this task, with a nifty trick to get round the limitations of a particular architecture.
This entry was posted in News. Bookmark the permalink.