[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] hw/arm: add Lego NXT board
From: |
Alexander Graf |
Subject: |
Re: [Qemu-devel] hw/arm: add Lego NXT board |
Date: |
Mon, 14 Jul 2014 20:09:48 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
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
- [Qemu-devel] hw/arm: add Lego NXT board, Alexander Graf, 2014/07/13
- Re: [Qemu-devel] hw/arm: add Lego NXT board, Peter Crosthwaite, 2014/07/14
- Re: [Qemu-devel] hw/arm: add Lego NXT board, Paolo Bonzini, 2014/07/14
- Re: [Qemu-devel] hw/arm: add Lego NXT board,
Alexander Graf <=
- Re: [Qemu-devel] hw/arm: add Lego NXT board, Paolo Bonzini, 2014/07/14
- Re: [Qemu-devel] hw/arm: add Lego NXT board, Alexander Graf, 2014/07/14
- Re: [Qemu-devel] hw/arm: add Lego NXT board, Peter Maydell, 2014/07/14
- Re: [Qemu-devel] hw/arm: add Lego NXT board, Paolo Bonzini, 2014/07/15
- Re: [Qemu-devel] hw/arm: add Lego NXT board, Alexander Graf, 2014/07/15
- Re: [Qemu-devel] hw/arm: add Lego NXT board, Paolo Bonzini, 2014/07/15
- Re: [Qemu-devel] hw/arm: add Lego NXT board, Alexander Graf, 2014/07/15
- Re: [Qemu-devel] hw/arm: add Lego NXT board, Paolo Bonzini, 2014/07/15
- Re: [Qemu-devel] hw/arm: add Lego NXT board, Alexander Graf, 2014/07/16
- Re: [Qemu-devel] hw/arm: add Lego NXT board, Paolo Bonzini, 2014/07/16