7 ms·
QSOE: QNX-inspired OS with dual-kernel architecture
- ymz5 3mo agoTo all experts in video cards reading this: Do you know, how to initialize a NVidia card in the RISC-V system (such as Unmatched or Polarfire) to the basic VGA mode 3 (text mode, 80x25)? :) I really wanted to get the Real Console for QSOE, but so far all my efforts to run video BIOS (via U-Boot's bios_emulator) are not successful...
- p_l 3mo agoDepending how recent the card is, you might need to implement UEFI & GOP instead. Might be better approach to read any open source driver code on Linux or BSD to find out how to get basic framebuffer
- ymz5 3mo agoExactly. After days of unsuccessful VideoBIOS bring-up (via U-Boot's emulator), I gave up, and implemented exactly what you suggested: graphics mode, using of course parts of nouveau. Claude Code is smart in extracting information. And it worked!! Now I have the picture on the monitor when U-Boot starts. The only one drawback: it takes 30..40 seconds between the moment of machine-power-on and the picture on the screen.
- d3Xt3r 3mo agoDo you have any plans (maybe in the far future) to re-implement the Photon microGUI system? Just asking because for me, that's half of what made QNX so great back in the day. Even today I keep raving about that 1.44MB demo floppy, about how polished, performant and efficient Photon was.
- ymz5 3mo agoWell.. who knows. My interests are not exactly in the area of GUIs, but I do agree that Photon was great. When the main system stabilizes; when it runs RT tests (such as the audio test I'm planning) under heavy load for e.g. one week -- AND when all important "syscall-like" APIs are implemented and proven to be correct -- I might return to this. Question to you: on which hardware platform would you like to have Photon running? Currently, the only system I got is SiFive Unmatched with NVidia GK-208 card. Re-using Nouveau in QSOE should be possible, but it's a big pile of work.
- d3Xt3r 3mo agoLow-spec/embedded/vintage devices. Mainly RISC-V, or old x86 hardware like a Pentium III with a Matrox Millennium AGP card or something. For context: I'm sick and tired of modern hardware, modern GUIs and modern Internet... all of which keeps getting more and more complex, commercialised, controlled and demanding. I miss the old days, when hardware resources were paltry, when you could mostly understand what went on in your hardware and OS, when developers coded in native languages, didn't rely on bloated toolkits and infinite dependencies and didn't take a user's system resources for granted and were able to make really cool programs in mere kilobytes, when the OS didn't impose arbitrary restrictions on you in the name of "security" and you were free to do whatever you wanted with it, and when the Internet wasn't controlled by mega corporations and there was no Javascript and browsers didn't need gigabytes of RAM and the web wasn't the bloated mess that it is today.... I really, really miss those days. My dream is to either have a RISC-V box or a vintage PC, hook it up to a LoRa network like Meshcore or something, run an efficient 90s-style OS like QNX/Haiku/SerenityOS/KolibriOS, and run some old-school networking apps similar to IRC, BBS or even Web 1.0, all over LoRa... and rediscover the joy and magic of computers again, relive the spirit of the 90s whilst being able to communicate with others freely without corporations and governments getting in your way... that's my dream. Sorry if I went off on a tangent, I just saw "QNX" in the headline and it got me all nostalgic and emotional.
- RetroTechie 3mo agoI share that dream, and surely it's not just us. Raspberry Pi was a shot in that direction. But it's still a complex beast with 3D GPU, some embedded RTOS to get everything started, etc. Personally I think software size should reflect the complexity of the task. And yes, a modern GUI does subpixel rendering of scalable fonts, decoding complex video codecs etc etc. But the bulk of today's massive software size is just pointless abstractions, inefficient 'frameworks' or eyecandy.
- ymz5 3mo agoRight. That's why I love good text mode interfaces so much.
- xvilka 3mo agoFor QNX/Blackberry it would make sense to opensource Photon since they are not using it anymore. Porting it to the modern QNX and other systems would be great.
- jonhohle 3mo agoIf anyone knows where to find a legitimate MIPS version of Photon, I’d be interested in starting a decomp project.
- m132 3mo agoI don't think a MIPS version ever existed. The only public releases that ran on MIPS (6.4 and pre-SP1 6.5) only bundled a handful of Photon-related binaries, which if my memory serves were just input drivers. There were x86 and more or less complete ARMv7, PowerPC, and SuperH ports.
- fouc 3mo agoI wonder if we couldn't just use LLMs to completely reverse engineer a QNX 4.25 demo image into usable source code. Possibly translate it directly into rust code. Bun had it easier in many ways, given that they're based on a well-documented public API surface & have the node.js test suite etc. In the case of QNX I'm guessing it might help to find a way to intercept the message passing of running QNX instances in order to use it as a test harness while reverse engineering all the components.
- d3Xt3r 3mo agoI reckon it should be feasible - especially if you start with the code in the 1.44MB demo disk. If you exclude the kernel, the network stack, the drivers and all the other apps, the binaries for Photon itself should be in kilobytes. Far more complex projects have been decompiled with LLMs.
- GaryBluto 3mo agoI contacted the QNX community relations manager a little time ago and (if I remember correctly) they said they weren't going to release any of the microGUI source as they wanted the community to focus on their current projects. Very saddening that all that useful historical source code is being left to rot.
- joshu 3mo agowill this work with liteX? fascinating project
- ymz5 3mo agoHmm.. how liteX is related to the QNX-inspired OS with selectable kernels? :)
- joshu 3mo agoUse litex to define/build a riscv soc-on-fpga, boot qsoe instead of Linux on said fpga?
- ymz5 3mo agoThanks for the clarification! Till today I didn't know you can build a 64-bit RISC-V CPU with LiteX. Cool! The only problem (for me) is the availability of suitable hardware to implement it :) The only FPGA board I got is GateMate EVB-A1.
- joshu 3mo agoWhere are you based, I can get you something beefier? I got a Tang Primer for one of my own projects recently.
- ymz5 3mo agoOh, don't worry (and thanks for the offer!) -- I'll soon have Artix 7 powered board (or may be even something "beefier"). At least the "Dragon Board" with Artix 7 I will need for the video controller for my Unmatched: it has a PCIe connector & HDMI connector.
- fithisux 3mo agoIs it a micro-kernel based? Because writing kernel drivers is not the most convenient approach.
- m132 3mo ago> Skimmer's design intentionally echoes DragonFly BSD's LWKT and msgport subsystems — the per-CPU runqueue, the lwkt_* API surface, the rule that cross-CPU work flows as messages rather than as direct foreign writes. DragonFly's source under ~/proj/OS/DragonFlyBSD/6.4.2/sys/kern/ was studied as a structural reference during v0.1 bring-up. https://gitlab.com/qsoe/nq/-/blob/bfe5337676ee3818d24db4101b11488be0bfbec9/README.md#design-and-provenance https://gitlab.com/qsoe/nq/-/blob/bfe5337676ee3818d24db4101b... Is this Claude going unsupervised? There are also references to CLAUDE.md ("see CLAUDE.md for scope") which is nowhere to be found.
- valentynkit 3mo ago[dead]
- dvt 3mo agoThis is one of the few AI hills I will die on: not disclosing AI tool usage when you produce a product where the writing is the end result (in this case, the website I'm being sent to) is disrespectful to your readers and users. `The quickest way to see QSOE run — no hardware, no -kernel juggling.` `Real hardware, real disk.` `A working plan, not a contract: milestones may shift as the work reveals what's really next.` I have no problem with using AI to draft docs, or as an editing tool, or even to help writing (if, e.g., you are not a native speaker) but this is just egregious low-effort slop. If you can't even put the time to write your own documentation (or at least disclose AI tool use), why would I trust you to even test your own sofware?