Early Boot and Late Attach in QNX

{{#invoke:Message box|ombox}}

Introduction

Heterogeneous multicore devices, like DRA7XX, often configure their individual cores into master/slave relationships. The master (e.g. DRA7XX's A15) often runs an HLOS like QNX, which manages slaves (e.g. DRA7XX's DSPs and IPUs) that run an RTOS like SYS/BIOS. The bootloader (e.g. u-boot) for the typical master/slave system loads/boots the HLOS, and once the HLOS has enabled enough infrastructure (e.g. file systems, device driver backplanes, etc), the HLOS loads/boots the slave devices.

In some use cases, however, it's important that features enabled by the [traditionally] slave devices become available ASAP, without waiting for the HLOS to boot. In this case, the system integrator might prefer to instead configure the cores into a peer-to-peer relationship, rather than the traditional master/slave. In this peer-to-peer configuration, the bootloader instead loads the RTOS-enabled cores and then the HLOS. This way, both cores independently boot, and the RTOS-running cores can enable functionality very early. This configuration is often called "Early Boot".

In this peer-to-peer configuration, once both HLOS and RTOS cores have independently booted and are ready to communicate with each other, they can establish a communication path. This post-boot handshaking is often called "Late Attach".

This feature has been enabled for DRA7XX, running QNX on the A15 and BIOS on the IPUs. This article describes the boot sequence with Early Boot, details to enable it, and potential issues you may encounter.

Boot Sequence

Early Boot starts with the bootloader. In our testing, we used a version of u-boot, which has been extended to support parsing a resource table, allocating the necessary memory and configuring the mmus, loading the IPUs code/data, and booting the IPUs (running BIOS) before it loads and boots the QNX IFS. You can also choose to use other bootloaders, so as long they can do the same.

Enabling Early Boot

If you are using u-boot, configure it according to the 'Enabling Early Boot' section of this article. Copy MLO and u-boot.img onto the boot partition of the SD card alongside 'QNX-IFS'.

Build the IPU1 binary (let's assume we want to early-boot IPU1 for sake of illustration) the way you normally do. Refer to the IPC Install Guide for details on how to build it.

Copy the resulting binary (e.g. messageq_single.xem4) to the SD card, alongside MLO and u-boot.img. Rename it to dra7-ipu1-fw.xem4. This is necessary because u-boot specifically looks for this filename.

Insert the SD card onto your EVM and power it up. You should be able to see the single stage bootloader come up on the console. Hit a key to prevent autoboot from continuing. Enter the following commands in u-boot to load and start the QNX IFS:

 fatload mmc 0 0x80100000 QNX-IFS
 go 0x80100000

Enabling Late Attach

After QNX is booted, launch the IPC resource manager by telling it to late-attach to the slave core. For example, to late-attach to IPU1, execute

 ipc -a1 IPU1 messageq_single.xem4

where 'messageq_single.xem4' is a copy of the same executable that was pre-loaded by u-boot. The '-aN' flag says tells IPC that the first N cores that are listed in the command have already been booted, and that it only needs to 'attach' to them to establish communication. Other cores (if specified) in the list would be loaded and booted by IPC as usual.

You can now run the host-side executable of your application as you normally would:

 ./MessageQApp 10 2

This should do 10 iterations of the MessageQApp (10) with IPU1 (2).

Potential issues

My Tasks on the slave core do not get to run until the host has launched the IPC resource manager

In most IPC examples, there is a line in the SYSBIOS configuration script (.cfg) file that calls IpcMgr_ipcStartup() in BIOS_start() in the context of main():

       //BIOS.addUserStartupFunction('&IpcMgr_ipcStartup');

This function spin-waits for the host to launch the IPC resource manager, and the call needs to be commented out if you want Tasks to be enabled on the slave so that it can do some 'work' before waiting for communication to be established with the host. The application would then call IpcMgr_ipcStartup() in their application whenever they are ready to establish communication with the host. Normally this is best done in a low-priority Task, so that higher-priority Tasks can run while this Task is spin-waiting for the host to launch the IPC resource manager. Only after this function returns can the application use MessageQ to talk to the host.