5 ms·

There are some other open OSs, like Zephyr, NuttX and Contiki - so maybe they're the right thing to use for the nommu case rather than Linux?

guerrilla 1y ago
xv6 already runs on RISC-V.
- throwaway2037 1y ago
  Wow, I am somewhat ashamed to admin that I had never heard of "xv6" until your comment! I found the MIT homepage here: https://pdos.csail.mit.edu/6.1810/2024/xv6.html https://pdos.csail.mit.edu/6.1810/2024/xv6.html Two things standout to me: (1) It was written in 2006. RISC V was not released until 2010 (so says Google). I guess it was ported from x86? (2) Russ Cox is one of the contacts listed on MIT homepage. That guy's digital footprints are enormous.
  - vulcan01 1y ago
    Yes, it was ported from x86. And no, xv6 is not really an OS you want to use in production. There are a lot of design decisions that optimize for pedagogy instead of performance or even reliability (e.g. the kernel is more than happy to panic if/when you get off the "intended path").
- s20n 1y ago
  xv6-riscv was designed to run on qemu-virt, not real hardware. you'll atleast need to use a fork like https://github.com/jrmenzel/vimix_os https://github.com/jrmenzel/vimix_os to get it to work on a real board.
RantyDave 1y ago
Zephyr is not an OS in the conventional sense, it's more a library you link to so the application can "go".
- ajross 1y ago
  Zephyr is an "OS" in pretty much every conventional sense. What you're saying, I think, is that a default build of Zephyr on a no-MPU device is a single shared .text segment where all the threads and other OS-managed objects are app-created by C code. So... sure, it's a library and an OS. And even when running on a system with an MPU/MMU, Zephyr tries hard to present that same API (i.e. function calls into the kernel become syscalls automatically, etc...), so the illusion is a fairly strong one. And given the target market (even the biggest Zephyr targets have addressable RAM in the megabytes, not gigabytes), there's no self-hosting notion. You build on a big system and flash to your target, always. So there's no single filesystem image (though it supports a somewhat limited filesystem layer for the external storage these devices tend to see) containing "programs" to run (even though there's a ELF-like runtime linker to use if you want it). If you want it to look like Linux: no, that's not what it's for. If you want to target a Cortex-M or ESP32 or whatever on which Linux won't run, it gives you the tools you expect to see.

guerrilla 1y ago

xv6 already runs on RISC-V.

throwaway2037 1y ago
Wow, I am somewhat ashamed to admin that I had never heard of "xv6" until your comment! I found the MIT homepage here: https://pdos.csail.mit.edu/6.1810/2024/xv6.html https://pdos.csail.mit.edu/6.1810/2024/xv6.html Two things standout to me: (1) It was written in 2006. RISC V was not released until 2010 (so says Google). I guess it was ported from x86? (2) Russ Cox is one of the contacts listed on MIT homepage. That guy's digital footprints are enormous.
- vulcan01 1y ago
  Yes, it was ported from x86. And no, xv6 is not really an OS you want to use in production. There are a lot of design decisions that optimize for pedagogy instead of performance or even reliability (e.g. the kernel is more than happy to panic if/when you get off the "intended path").
s20n 1y ago
xv6-riscv was designed to run on qemu-virt, not real hardware. you'll atleast need to use a fork like https://github.com/jrmenzel/vimix_os https://github.com/jrmenzel/vimix_os to get it to work on a real board.

RantyDave 1y ago

Zephyr is not an OS in the conventional sense, it's more a library you link to so the application can "go".

ajross 1y ago
Zephyr is an "OS" in pretty much every conventional sense. What you're saying, I think, is that a default build of Zephyr on a no-MPU device is a single shared .text segment where all the threads and other OS-managed objects are app-created by C code. So... sure, it's a library and an OS. And even when running on a system with an MPU/MMU, Zephyr tries hard to present that same API (i.e. function calls into the kernel become syscalls automatically, etc...), so the illusion is a fairly strong one. And given the target market (even the biggest Zephyr targets have addressable RAM in the megabytes, not gigabytes), there's no self-hosting notion. You build on a big system and flash to your target, always. So there's no single filesystem image (though it supports a somewhat limited filesystem layer for the external storage these devices tend to see) containing "programs" to run (even though there's a ELF-like runtime linker to use if you want it). If you want it to look like Linux: no, that's not what it's for. If you want to target a Cortex-M or ESP32 or whatever on which Linux won't run, it gives you the tools you expect to see.