ymz5

The initiative originates in Europe, thus it's European. It aims at solving very concrete problems, particularly about running RTOSes used in industrial computing, and efficient resource partitioning. It invites industrial companies to join.

Or what exactly was your question about?

What "that approach"? In the scope of the initiative, we are talking about full isolation of operating systems (which is possible with the hypervisor). I still don't understand why are you offering me to read about L4 and RT-Linux.

(QSOE/L does use seL4 as one of its possible kernels. But I guess you also haven't noticed this, because, perhaps, you don't care.)

Excuse me, but what Barabanov, Yodaiken and all the stuff you mentioned have to do with the subject?

Have you noticed that Linux on the diagram is a general-purpose OS, used for non-critical tasks? Or, refusing to watch the video, you refuse also to see what's actually depicted on the page?

> it's been working since the 01990s

What's been working since the "01990s"? What hypervisor in 1990s drove real-time OSes on industrial computers alongside general-purpose OSes, providing full resource isolation?

> ERICI's plan to run Linux under a real-time hypervisor...

Why plan? It's working right now, alongside QSOE/N. Resources nicely partitioned: graphics controller and UFS storage for Linux; NVMe, Ethernet UART for QSOE. Please see the demonstration video.

> ... the device tree blob could/would be embedded in the same package as this HFI firmware

Why "could/would"? It is part of the firmware, now. HFI BIOS is U-Boot + VideoBIOS + Set-Up program. Its job is to initialize your hardware (video controller included) and start your boot loader (EFI program), just like in a PC.

> ... even if the main NAND/emmc/SSD hosting the OS is wiped out

There is [almost] always the possibility of recovery. I have three RISC-V systems, and each of them cannot be "bricked": * X-Modem for VF2; * SD-card boot for Unmatched; * fastboot (Android) protocol for the K3

> on PCs, there is usually a NOR flash that hosts the BIOS/UEFI.

Same on Unmatched, for example: you may store HFI BIOS in NOR (boots very fast!), or on your SD card (boots slow, only 81 KB/sec). What to boot from is selected by DIP switches. Similar mechanism on VF2 too.

> Where is Siemens and Bosch these days…

Hopefully they praise the initiative. ;-)

It is supposed to be a sturdy industrial computer with a RVA23-capable SoC inside, capable of running two or more OSes simultaneously. At least one of those OSes must be a hard-real-time OS, used e.g. in control or robot tasks.

> Why the emphasis on RVA23?

Easy. In fact, the emphasis will be on RVA23 _and_ on working IOMMU hardware. This is needed for hardware resource isolation between operating systems running on the hypervisor.

RVA23 is mandatory for Ubuntu, for example. So the requirement is not new at all.

No, I did not. Are you looking at some other page?

Would be happy to port the stack to a RVA23-capable system from Cortus, Codasip or any other European firm! Once the board is available, of course.

Author here. Happy to answer technical questions: about HFI BIOS, partitioning hypervisor (gRouvr), QSOE RTOS.

I hope that leading European industrial computer manufacturers notice the initiative and join -- or at least start evaluating the possibility to use RVA23 SoCs in their devices. Yes, currently only Chinese vendors can provide such chips, but the world is changing fast.

Have you noticed the words "non-commercial" at the bottom of the page?

The random dude is not looking for funding.

HFI itself is the Initiative (coordination, collaboration, standardization). HFI BIOS is the reference implementation.

Oh, 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.

Exactly. 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.

Thanks 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.

Hmm.. how liteX is related to the QNX-inspired OS with selectable kernels? :)

Well, obviously: if it's "QNX-like", then it IS microkernel-based.

Don't worry, it's being fully supervised :) . Yes, almost the entire product is developed with Claude.

Right.

That's why I love good text mode interfaces so much.

Fully support your dream -- and out of similar reason/sentiments I created GateMate PC (google for it) and GateMate S/359. I will return to these systems in autumn; it's a pure joy to work with them.

As for the video controller -- if during the next couple of days I have zero success with GK-208 initialization in U-Boot, I have a plan B. I will throw away that card completely and will buy DragonBoard (Xilinx Artix 7). I already have a video controller implementation for it.

Own video-controller + own OS + own bootloader on RISC-V. What could be better! :D

Well.. 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.

To 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...

Now on bare metal too:

https://r-tty.blogspot.com/2026/04/qrv-v021-interactive-shel...

The system boots fully, in SMP mode, to the userspace shell.

There is also an idea of attaching the RP2350 to the "mainframe". Olimex GateMateA1-EVB has plenty of lines to organize the parallel interface to e.g. Raspberry Pi Pico 2.

Well, there's a plan in case BB doesn't re-license.

We will rewrite the proprietary parts of the kernel from scratch. It's not trivial, but possible.

We could use seL4 as a basis for the "core" message-passing primitives. Channels and connections will go next.

"read-only type license" -- that's a bit too strong wording.

OTTAWA, September 12, 2007 — [...] QNX Software Systems today announced that it is opening access to the source code of its QNX® Neutrino® realtime operating system (RTOS) under a new hybrid software licensing arrangement.

Effective immediately, QNX will make source code for its [...] microkernel-based OS available for download. The first source release includes the code to the QNX Neutrino microkernel, the base C library, and a variety of board support packages (BSPs) for popular embedded and computing hardware.

Not only can developers view the QNX Neutrino source code, but they can improve, modify, or extend that code for their own purposes or for the QNX community at large.

Thanks, chrsw! I encourage people to join the petition to re-license old QNX sources under Apache 2.0. If Blackberry does so, we'll have another good and free microkernel-based OS.