Page History

The NuttX

...

The NuttX simulation is a port of NuttX to run as a process under Linux or Cygwin and probably other POSIX contexts as well.

Reference: The sim configuration README file.

How the Simulator is Built

The simulator isn't a virtual machine or anything like that. It is just a single thread that implements a non-preemptive version of NuttX using setjmp/longjmp to do the context switches.

http://nuttx.org/Documentation/simulation.pngImage RemovedImage Added

The nuttx.rel Blob

The first thing that you have to understand is how the simulation is built. Look at arch/sim/src/Makefile. This target builds the NuttX executable (simplified for clarity):

...

The second $(OBJCOPY) line is the thing the irrevocable severs the NuttX "fish bowl" from the host environment. It renames most of the symbols in nuttx.rel so that they do not collide with the symbols use by the host system. Look in arch/sim/src/nuttx-names.dat. So open() becomes NXopen(), close() becomes NXclose(), read becomes NXread(), etc.

The $(HOSTOBJ) Blob

The $(HOSTOBJS) contains the final host interface. This is the host PC blob and in this one, there is no re-naming: open() goes to the real system open(), close() goes to the real system close(), etc. When these two blobs are linked together in the final $(CC), you have the simulation.

Accessing Host Devices Using FIFOs?

General Concepts

When you write the code in the simulation, it runs in the NuttX blob and can only interface with NuttX interfaces. It cannot interact directly with the host system. It cannot open(), close(), read(), or access a host device driver in any way (because it cannot get to the host system namespace).

...

If you want to access a host device driver, then the code that does that has to reside in the Host blob (i.e., it is in $(HOSTOS)). Only there can it interact with the host OS. And there, you can do things like create a host pthread to service a device interface. That pthread can wait for I/O without blocking the whole simulation on the main thread (that is how the simulated console I/O works, for example).

Toward a General Design

There is no design in place for accessing Host devices from the simulation. Here are some directions that I would investigate, however.

...

    NuttX Target Code <--->NuttX FIFO<--->Host Interface<---->Host Driver

What is Wrong With That?

There is a one big problem: if logic in the Host blob calls NXwrite(), that could potentially cause a NuttX context switch. Remember that a context switch is really a setjmp() that saves the current context followed by a longjmp() that switches to the new context. All of this must happen on the main thread of the simulation.

...

Pretty kludgey. This just begs for a better solution. If only the simulation supported interrupts...

...

Simulated Interrupts

The current NuttX host simulation has no interrupts and, hence, is non-preemptible. Also, without simulated interrupts, there can be no high-fidelity simulated device drivers or precise timer interrupt.

...

Issues. My only real technical questions involve signal masking. When the SIGUSER signal handler executes, the SIGUSER interrupt will be masked. That would prevent any further context switches until the signal handler returns. Can we simply unmask SIGUSER signal to get more context switches? I would need to experiment to know for sure.

Supported Devices

Serial Console

...

The simulation's serial console is provided by wrapping host stdin and stdout so that it appears to be /dev/console. Serial data from the host stdin is sampled in the IDLE loop. If serial data is available, the IDLE loop will post simulated UART activity. The fidelity of this simulation could be improved with simulated interrupts when UART data is avaiable.

Host File System Access

Host file system access is supported via the nxfuse user-space file system that you can find in the NuttX tools repository. Instructions for using the nxfuse file system can be found in a README file in that repository directory.

Networking

Networking is supported for the simulation using TUN/TAP interface under Linux or using WPCap under Windows. A README file providing instruction for setting up the TUN/TAP interface under Linux is provided in the NuttX repository. The network is again handled by the IDLE loop in the simulator and could benefit from simulated interrupts.

USB

At one time, there was an effort underway on GitHub to port libusb into NuttX in order to support USB devices in the simulation. That effort was never completed although is it still a very good idea.

LCD

X11 framebuffers can be used to simulate NuttX graphics framebuffer devices. These are, again, managed in the IDLE loop.

SMP

There is a simulator configuration has basic support for SMP testing. The simulation supports the emulation of multiple CPUs by creating multiple pthreads, each run a copy of the simulation in the same process address space.

...

Apparently, if longjmp is invoked from the context of a signal handler, the result is undefined: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1318.htm^{Image RemovedImage Added}

You can enable SMP for ostest configuration by enabling:

...