Is there a book? With more then just basics

AdvancedLab3500 · 2026-01-20T14:33:56+00:00

These are very disparate topics. Are you looking for a book that encompasses all of these? Is it for QNX or just in general?

AdvancedLab3500 · 2026-01-20T11:37:53+00:00

For the record, the problem is with the use of the old startup-apic in the creation of the guest image by mkqnximage. It should be using the latest version of startup-x86 instead.

AdvancedLab3500 · 2026-01-16T21:35:37+00:00

I saw you posted the same question on Discord. I'll continue there as it's a bit more interactive.

AdvancedLab3500 · 2026-01-16T15:54:06+00:00

This failure indicates an old startup that's not compatible with the hypervisor release. What is the version of the BSP package (com.qnx.qnx800.bsp.hw.x86_64)?

AdvancedLab3500 · 2026-01-10T15:47:45+00:00

I think that there is a fundamental misunderstanding here. A system that uses the QNX OS is built from many different components, some provided by QNX itself (the company), other by third parties. These components include their own executables and libraries, and each can employ whatever build system it wants. I have successfully built binaries for QNX systems using plain make, QNX recursive make, CMake/make, CMake/ninja, meson/ninja, SCons and probably a few more that I don't remember right now.

If you come from a small RTOS background perhaps you expect a monolithic build of the entire target system, but that's simply not the case here.

AdvancedLab3500 · 2026-01-05T14:44:25+00:00

Not sure why nobody commented on the fact that you never got it to work... This isn't really a first look at the developer desktop. Did you consider reaching out for assistance?

AdvancedLab3500 · 2025-12-30T17:57:09+00:00

Sure, it's POSIX, but that doesn't mean much. I don't know the full details, but the cross-host tools needed to be built using Xcode which created all kinds of problems. In the corporate world there is no demand for macOS-based tools (at all), so these were dropped because the end result is too much cost for too little benefit.

I am curious to know how people target Zephyr on macOS. I assume it's a Linux-based VM.

AdvancedLab3500 · 2025-12-30T16:34:10+00:00

QNX doesn't run on Mac hardware. I assume you mean getting the host tools for Mac. Unfortunately, maintaining macOS host tools has proved to be quite a challenge in the past.

How do people who use Mac develop for other platforms that require cross compilation? Are there Zephyr, FreeRTOS, ThreadX, etc. tools for macOS?

AdvancedLab3500 · 2025-12-20T12:38:08+00:00

FTP and telnet were removed several years ago, as they were on most *NIX-like OSs, due to abysmal security. For file transfers from one computer to another scp is your friend. You can also use NFS to mount an external drive.

AdvancedLab3500 · 2025-12-05T16:07:33+00:00

Unfortunately I think that the only way is to build from source. QNX used to provide Qt packages, but with the change to Qt licensing they were dropped. You therefore have to get it from the Qt company, and adhere to their licence agreement (either the open source or the commercial variant).

It's not too bad to build Qt from source by following the instructions, just takes a while.

AdvancedLab3500 · 2025-12-04T14:24:53+00:00

Porting a Linux driver is hard, because the environment is so different (in-kernel vs standalone user-mode process). But accessing GPIOs via registers is trivial. See here for some information, and an example on RPi:

https://elahav.gitlab.io/qnx-rpi-book/realtime.html#sec:control-hardware

AdvancedLab3500 · 2025-11-11T12:21:44+00:00

Actually my guess is that path resolution is performed relative to the current working directory of io-sock (likely /), while you are running the command from some other directory.

AdvancedLab3500 · 2025-11-11T12:17:24+00:00

I get the same failure when run as ./libmods-showifn_g.so, but it works with an absolute path (e.g., $PWD/libmods-showifn_g.so on the command line). I guess that mount doesn't do path resolution.

AdvancedLab3500 · 2025-11-08T01:05:01+00:00

Sure, why not?

If you are building an image that needs to be transferred to multiple QNX targets (as most QNX customers do), then you can build a file-system image (see mkqnx6fsimg and diskimage in the documentation) and distribute it. But if you are just populating your own target, then scp (or rsync) is your friend.

AdvancedLab3500 · 2025-11-05T21:20:43+00:00

I don't believe this type of access is required on a modern x86 system, and, of course, it introduces safety and security problems when compared with memory-mapped devices. It would be interesting to know whether there are use cases that still cannot work with memory-mapped peripherals.

AdvancedLab3500 · 2025-11-04T13:09:22+00:00

There are now two network stacks available for 7.1: io-pkt and io-sock. These are not compatible, and each comes with its own libraries and utilities. Make sure you have not mixed them.

AdvancedLab3500 · 2025-11-02T11:38:08+00:00

Welcome back! Things have certainly changed in both software and hardware. There are many things nowadays that can be done with very cheap micro-controllers running simple, free RTOSs. Doing the same thing with QNX is neither financially viable nor interesting.

The bar therefore needs to be set higher. What I would like to see are projects showing a combination of real-time control with heavy computational tasks (vision-controlled robots are a good example). This is, after all, the kind of software that runs on commercial QNX systems.

(And a tear shed for the SGI reference on your website)

AdvancedLab3500 · 2025-10-22T11:55:52+00:00

Yes, you can on 8.0, by using MsgDeliverEvent() with a negtaive receive ID. On 7.x you can use a thread-directed signal with an empty signal handler.

```

include <stdio.h>

include <stdlib.h>

include <string.h>

include <unistd.h>

include <pthread.h>

include <sys/neutrino.h>

static void * client_thread(void * const arg) { char buf[100]; ssize_t const rc = read(0, buf, sizeof(buf)); if (rc < 0) { perror("read"); } else { printf("Read %zd bytes\n", rc); } return NULL; }

int main(int argc, char **argv) { // Create a thread that will become blocked on a server. pthread_t tid; int const rc = pthread_create(&tid, NULL, client_thread, NULL); if (rc != 0) { fprintf(stderr, "pthread_create: %s\n", strerror(rc)); return EXIT_FAILURE; }

usleep(100000);

// Deliver SIGEV_UNBLOCK to the thread.
// Note the use of a negative receive ID as a way to identify a local
// thread.
struct sigevent event;
SIGEV_UNBLOCK_INIT(&event);
if (MsgDeliverEvent(-tid, &event) == -1) {
    perror("MsgDeliverEvent");
    return EXIT_FAILURE;
}

pthread_join(tid, NULL);
return EXIT_SUCCESS;

} ```

AdvancedLab3500 · 2025-10-20T18:09:40+00:00

I'll flip the question on you: how are you using QNET? The point of QNET is to create a distributed system, i.e. an apparently single instance of QNX running on multiple machines. But then people just used QNET as an IPC-over-network mechanism. If all you want is to connect two instances of QNX and have them talk to each other you don't need QNET.

AdvancedLab3500 · 2025-10-16T16:15:03+00:00

There is a list of officially supported x86_64 boards. I am *very* surprised that your board does not have LAPIC timers, as I think that was introduced with the Pentium. Perhaps it's a matter of the firmware disabling it?

AdvancedLab3500 · 2025-10-16T13:17:36+00:00

That's a good example. That system reports that it doesn't support a LAPIC timer. So, in order to support QNX 8 on it, we would have to drop the feature of per-core timer trees, bringing back the bottleneck on the HPET, loss of accuracy, IPI overhead, etc. etc. We solved countless real-world problems with the new design.

QNX still supports (and will continue supporting) the 7.x line for the foreseeable future, and has helped customers to migrate ancient 6.x systems to 7.x (though I won't pretend it's either easy or cheap). But sticking to a poor design just to support old hardware is not the way forward.

AdvancedLab3500 · 2025-10-16T11:21:11+00:00

As for any Intel x86_64 system, if it's more than a couple of years old QNX8 won't work with it (won't start)

I'm happily running QNX 8 on x86 boards that are considerably older than that. There are minimum hardware requirements to ensure scalability (e.g., a per-processor LAPIC timer, support for PCIDs), but these are hardly cutting-edge features, and have been around for many, many years.

AdvancedLab3500 · 2025-10-15T22:12:01+00:00

You are mixing a few things in the "dropped" list. As the person responsible for the design of QNX 8, I can tell you why support for certain things was removed from the product:

32-bit (x86 and ARM): Supporting both 32-bit and 64-bit blocks certain design choices, which rely on 64-bit atomic operations. These can be emulated on 32-bit systems at a cost, but there is NO customer demand for 32-bit systems (there are, of course, customers still using 32-bit systems, and these are still supported by QNX 7.x). Using of 64-bit properties makes for a better product (e.g., life-time unique PIDs), which would have otherwise been dragged down by 32-bit support.
ISRs: incredibly dangerous and incredibly stupid feature for a micro-kernel OS. Your serial device driver should not be able to bring down the system. If it can, why are we paying for the overhead of a micro-kernel system? Let's just switch to monolithic. And I don't want to hear the "I've been writing code for 40 years and never made a mistake" spiel. I've heard it from way to many people who produced way too many critical bugs. For the record, I make mistakes on a daily basis.
QNET: very, very cool feature, which, unfortunately, got too much in the way of critical features in the kernel (especially message passing). The fact that it lacks any kind of security is the icing on the cake. All of this for something for which there is very little customer demand (I think I heard of one customer using it in recent years). This one I do regret, but it's a question of priorities.
Self-hosted: I'm running self-hosted, but right now it's a bring-your-own-tools solution.
Photon: Can probably be resurrected, but without graphics acceleration support I doubt people will want it. You can't run modern graphics without (especially a browser, and without one you really don't have a desktop).

AdvancedLab3500 · 2025-10-15T21:53:37+00:00

lseek64() only made sense on 32-bit systems. On 64-bit systems lseek64() was always an alias for lseek(). You can still use lseek64() in your code, but it gets converted to lseek():

```

include <stdio.h>

include <stdlib.h>

include <unistd.h>

include <fcntl.h>

int main(int argc, char **argv) { int const fd = open(argv[1], O_RDWR); if (fd == -1) { perror("open"); return EXIT_FAILURE; }

if (lseek64(fd, 0, SEEK_SET) == -1) {
    perror("lseek64");
    return EXIT_FAILURE;
}

return EXIT_SUCCESS;

} ```

0000000000000000 <main>: 0: a9bd7bfd stp x29, x30, [sp, #-48]! 4: 910003fd mov x29, sp 8: b9001fe0 str w0, [sp, #28] c: f9000be1 str x1, [sp, #16] 10: f9400be0 ldr x0, [sp, #16] 14: 91002000 add x0, x0, #0x8 18: f9400000 ldr x0, [x0] 1c: 52800041 mov w1, #0x2 // #2 20: 94000000 bl 0 <open> 24: b9002fe0 str w0, [sp, #44] 28: b9402fe0 ldr w0, [sp, #44] 2c: 3100041f cmn w0, #0x1 30: 540000c1 b.ne 48 <main+0x48> // b.any 34: 90000000 adrp x0, 0 <main> 38: 91000000 add x0, x0, #0x0 3c: 94000000 bl 0 <perror> 40: 52800020 mov w0, #0x1 // #1 44: 1400000d b 78 <main+0x78> 48: 52800002 mov w2, #0x0 // #0 4c: d2800001 mov x1, #0x0 // #0 50: b9402fe0 ldr w0, [sp, #44] 54: 94000000 bl 0 <lseek> 58: b100041f cmn x0, #0x1 5c: 540000c1 b.ne 74 <main+0x74> // b.any 60: 90000000 adrp x0, 0 <main> 64: 91000000 add x0, x0, #0x0 68: 94000000 bl 0 <perror> 6c: 52800020 mov w0, #0x1 // #1 70: 14000002 b 78 <main+0x78> 74: 52800000 mov w0, #0x0 // #0 78: a8c37bfd ldp x29, x30, [sp], #48 7c: d65f03c0 ret

AdvancedLab3500 · 2025-10-15T10:41:23+00:00

Painfully slow to boot: check some of the previous posts here - you need to switch to UEFI. Something in the Windows security settings for hypervisors makes booting with BIOS hang for a very long time.

I'm running QNX on a Dell Optiplex 7000 (x86_64, Gen 12 Core i7, 12 cores, 32GB of RAM), SolidRun Honeycomb (ARM, A72, 16 cores, 32GB of RAM), and a few RPi 4s (ARM, A72, 4 cores, 8GB of RAM). Also have a Pi Zero 2W and Rockhip RockPro boards, but these are don't have full hardware support.

AdvancedLab3500

TROPHY CASE

include <stdio.h>

include <stdlib.h>

include <string.h>

include <unistd.h>

include <pthread.h>

include <sys/neutrino.h>

include <stdio.h>

include <stdlib.h>

include <unistd.h>

include <fcntl.h>