Re: [Qemu-devel] hw/arm: add Lego NXT board

[Alexander Graf]

On 07/14/2014 01:46 PM, Paolo Bonzini wrote:
> Il 13/07/2014 16:20, Alexander Graf ha scritto:

> > The
> > environment simulator is an external program which is connected to
> > several qemu instances via posix named pipes using a simple
> > communication protocol. Without pipe interaction the emulator can still
> > be used to debug NXT firmware images without sensor/actuator interaction.
>
> What does your protocol look like, and what kind of bus do the actual
> sensors and actuators use?
>
> If it is I2C or SPI, having generic i2c-over-chardev or spi-over-chardev
> protocols and devices would be a nice addition to QEMU.

The actual sensor hardware is not emulated. This was not required for my 
demand to inject sonsor values. I use an abstraction over the sensor 
hardware using IO memory. My firmware is something like:

uint32_t readUltrasonicSensor()
{
#ifdef QEMU_SIMULATION_IMAGE
        // This triggers pipe communication in Qemu
        // No hardware emulation
        return SOME_IO_MEMORY_REGISTER_SPECIFIC_FOR_THE_SENSOR;
#else
        // do the actual I2C bus transaction to read the value
#endif
}

So the protocol basically allows to forward read and write accesses on 
IO memory to processes outside of Qemu.

My protocol uses two named pipes as transport. One from Qemu to an 
outside process and one back into Qemu. It is a binary protocol with 
basically three messages:

get:
request: REQUEST_GET | uint16_t sequence # | uint16_t requested register
response: uint16_t sequence # | uint32_t register content

set:
request: REQUEST_SET | uint16_t sequence # | uint16_t register | 
uint32_t register value
response: uint16_t sequence #

sync tick:
request: REQUEST_TICK | uint16_t sequence #
response: uint16_t sequence #

Get and set transactions are triggered by Qemu on an IO memory read 
operation or write operation respectively. The pipe communication blocks 
Qemu until a value is available/the value was published.

The sync tick operation is to tell the remote process that the system 
tick timer interrupt has occured. (Another requirement for my SIL 
simulator.) For a generic memory-io-over-chardev device this could be 
removed. In addition for a truly generic implementation the memory 
access size (byte, word, ... access) needs to be integrated into the 
protocol.

I like the *-over-chardev idea. This could be a benefit for people who 
want to couple simulators or test oracles for embedded system tests or 
in general to other software in a simple way.

Regards
Alexander