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

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

[Alexander Graf]

Hi,

I developed a software in the loop simulator for the Lego Mindstorms NXT 
brick. It uses the Qemu ARM emulator to run the Robot's Firmware. I plan 
to release the simulator as an open source project. Now, I wonder if it 
makes sense to integrate the Qemu board implementation back into Qemu 
mainline or simply maintain it as an external set of patches.

The problem is that the qemu board I designed is not self-contained. It 
allows the firmware to read/write IO memory in order to read back sensor 
values from the simulated environment and to control actuators. 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.

I'm happy to prepare a patch, but do you think it is of any value to 
integrate code that is not 100% self contained?

Best Regards
Alexander

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

[Peter Crosthwaite]

On Mon, Jul 14, 2014 at 12:20 AM, Alexander Graf <alex@antistatix.de> wrote:
> Hi,
>
> I developed a software in the loop simulator for the Lego Mindstorms NXT
> brick. It uses the Qemu ARM emulator to run the Robot's Firmware. I plan to
> release the simulator as an open source project. Now, I wonder if it makes
> sense to integrate the Qemu board implementation back into Qemu mainline or
> simply maintain it as an external set of patches.
>
> The problem is that the qemu board I designed is not self-contained. It
> allows the firmware to read/write IO memory in order to read back sensor
> values from the simulated environment and to control actuators. 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.
>

Sounds like self contained functionality to me :) People have
gone-to-list with less.

> I'm happy to prepare a patch, but do you think it is of any value to
> integrate code that is not 100% self contained?
>

Many first-round series are not self contained and tend be not much
more that "boot the bare minimum software and lets add I/O features
later".

Regards,
Peter

> Best Regards
> Alexander
>

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

[Paolo Bonzini]

Il 13/07/2014 16:20, Alexander Graf ha scritto:
>
> The problem is that the qemu board I designed is not self-contained. It
> allows the firmware to read/write IO memory in order to read back sensor
> values from the simulated environment and to control actuators. 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.

Paolo

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

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

[Paolo Bonzini]

Il 14/07/2014 20:09, Alexander Graf ha scritto:
> So the protocol basically allows to forward read and write accesses on
> IO memory to processes outside of Qemu.
>
> 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 obvious thing to consider is whether this could be used to 
circumvent the GPL.

I think a generic memory-mapped I/O device interface is not a good idea 
in this respect, also because it's hard to get it right.  But i2c is 
simple enough, and there are so many devices with a 4-page datasheet, 
that I think it would be acceptable.  You could also write an i2c 
passthrough chardev backend that connects to /dev/i2c* and lets the 
guest access slaves in the host.

Paolo

> 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.

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

[Alexander Graf]

On 07/14/2014 10:37 PM, Paolo Bonzini wrote:> The obvious thing to 
consider is whether this could be used to
 > circumvent the GPL.
 >
 > I think a generic memory-mapped I/O device interface is not a good idea
 > in this respect, also because it's hard to get it right.
Okay, if this is a concern I will have to keep my changes off the 
mainline as it is a required feature.

 > But i2c is
 > simple enough, and there are so many devices with a 4-page datasheet,
 > that I think it would be acceptable.  You could also write an i2c
 > passthrough chardev backend that connects to /dev/i2c* and lets the
 > guest access slaves in the host.

My interest is to fake sensor values for the guest and not to connect 
anything to real hardware. I think I misinterpreted your "chardev". To 
clarify: My guest is a bare metal ARM image, no linux and I don't want 
to interact with the host's hardware. So no chardev in the linux sense 
is involved.

Anyway thank you for your feedback.

Regards
Alexander

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

[Peter Maydell]

On 14 July 2014 22:10, Alexander Graf <graf@campus.tu-berlin.de> wrote:
> On 07/14/2014 10:37 PM, Paolo Bonzini wrote:
>> But i2c is
>> simple enough, and there are so many devices with a 4-page datasheet,
>> that I think it would be acceptable.  You could also write an i2c
>> passthrough chardev backend that connects to /dev/i2c* and lets the
>> guest access slaves in the host.
>
> My interest is to fake sensor values for the guest and not to connect
> anything to real hardware. I think I misinterpreted your "chardev". To
> clarify: My guest is a bare metal ARM image, no linux and I don't want to
> interact with the host's hardware. So no chardev in the linux sense is
> involved.

Right, but this is an optional part of Paolo's proposal as I understand
it. You could just have your fake sensors be implemented by some
userspace process on the other end of a filedescriptor, as you do now
but with i2c rather than custom protocol. This would also let you run
the same bit of firmware in the guest as would be on the real h/w.

thanks
-- PMM

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

[Paolo Bonzini]

Il 15/07/2014 00:48, Peter Maydell ha scritto:
>> > My interest is to fake sensor values for the guest and not to connect
>> > anything to real hardware. I think I misinterpreted your "chardev". To
>> > clarify: My guest is a bare metal ARM image, no linux and I don't want to
>> > interact with the host's hardware. So no chardev in the linux sense is
>> > involved.
> Right, but this is an optional part of Paolo's proposal as I understand
> it.

Correct, it's an additional part just to show that the interface can be 
useful for much more than bypassing the GPL. :)

As to the protocol, I found a datasheet of an I2C-to-UART bridge that 
could provide ideas: 
http://www.nxp.com/documents/data_sheet/SC18IM700.pdf chapter 7, it's 
very simple (just two commands, start and stop).

Paolo

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

[Alexander Graf]

On 07/15/2014 12:48 AM, Peter Maydell wrote:
> Right, but this is an optional part of Paolo's proposal as I understand
> it. You could just have your fake sensors be implemented by some
> userspace process on the other end of a filedescriptor, as you do now
> but with i2c rather than custom protocol. This would also let you run
> the same bit of firmware in the guest as would be on the real h/w.
>

Ah, thank you, I finally realised that you are talking about the
-chardev argument (I just discovered that option.) and not only about
linux character devices. It seems I reinvented the wheel while
implementing the pipes. What a waste of time :)

On 07/15/2014 09:06 AM, Paolo Bonzini wrote:
> As to the protocol, I found a datasheet of an I2C-to-UART bridge that
> could provide ideas:
> http://www.nxp.com/documents/data_sheet/SC18IM700.pdf chapter 7, it's
> very simple (just two commands, start and stop).
Thanks for the idea. I still don't get why it should be better to fake
an I2C device rather than a universal memory IO. I don't want to emulate
the controllers hardware, but only communicate the abstract
sensor/actuator values. In addition not all Sensors are I2C devices, so
there is no value in doing it via an I2C bus. Even the simple I2C
protocol mentioned in the data sheet is more complex than mine.

Could you point me to the code where the chardev devices are defined in
qemu?

Alexander

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

[Paolo Bonzini]

Il 15/07/2014 12:26, Alexander Graf ha scritto:
> Thanks for the idea. I still don't get why it should be better to fake
> an I2C device rather than a universal memory IO.

Because this would not be fake, the idea was to emulate the actual 
sensor/actuator outside QEMU.  Which makes sense for much more than 
bypassing the GPL.  You listed some uses (test oracles), I added more 
(passthrough using the same chardev-based interface), and on top of this 
the devices are usually so stupid that there's not much point in 
bypassing the GPL in the first place.

> I don't want to emulate
> the controllers hardware, but only communicate the abstract
> sensor/actuator values. In addition not all Sensors are I2C devices, so
> there is no value in doing it via an I2C bus. Even the simple I2C
> protocol mentioned in the data sheet is more complex than mine.

That datasheet also has some GPIO pins, whether you need that depends on 
the I2C sensors and actuators you care about.  In the end it's just two 
commands (start and stop).

SSI is even simpler, it's just write a byte to the chardev, read a byte 
from the chardev.

In any case yeah, that's why I asked what protocol do the devices use in 
the actual hardware.

If the hardware is really using memory-mapped registers, the external 
program can talk to QEMU via QMP and set QOM properties and qom-set. 
There is an example in hw/misc/tmp105.c and tests/tmp105-test.c

Of course you could do that for all sensors instead of going to I2C (as 
you are doing now).  However, QEMU already has I2C and SSI emulation so 
I don't see much value in paravirtualization.

> Could you point me to the code where the chardev devices are defined in
> qemu?

Not sure I understand the question so -> irc. :)

Paolo

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

[Alexander Graf]

On 07/15/2014 12:53 PM, Paolo Bonzini wrote:
> Il 15/07/2014 12:26, Alexander Graf ha scritto:
>> Thanks for the idea. I still don't get why it should be better to fake
>> an I2C device rather than a universal memory IO.
>
> Because this would not be fake, the idea was to emulate the actual
> sensor/actuator outside QEMU.  Which makes sense for much more than
> bypassing the GPL.  You listed some uses (test oracles), I added more
> (passthrough using the same chardev-based interface), and on top of this
> the devices are usually so stupid that there's not much point in
> bypassing the GPL in the first place.
 >
 >> I don't want to emulate
 >> the controllers hardware, but only communicate the abstract
 >> sensor/actuator values. In addition not all Sensors are I2C devices, so
 >> there is no value in doing it via an I2C bus. Even the simple I2C
 >> protocol mentioned in the data sheet is more complex than mine.
 >
 > That datasheet also has some GPIO pins, whether you need that depends on
 > the I2C sensors and actuators you care about.  In the end it's just two
 > commands (start and stop).
 >
 > SSI is even simpler, it's just write a byte to the chardev, read a byte
 > from the chardev.
 >
 > In any case yeah, that's why I asked what protocol do the devices use in
 > the actual hardware.
 >
 > If the hardware is really using memory-mapped registers, the external
 > program can talk to QEMU via QMP and set QOM properties and qom-set.
 > There is an example in hw/misc/tmp105.c and tests/tmp105-test.c
 >
 > Of course you could do that for all sensors instead of going to I2C (as
 > you are doing now).  However, QEMU already has I2C and SSI emulation so
 > I don't see much value in paravirtualization.
 >

Sorry, I really don't get your point.

1. I do paravirtualization (thank you for giving me some vocabulary - 
I'm a virtualization newbe) for a reason; because my emulation is not 
interested in the details. I don't want real device behavior and I don't 
have time to implement it. There is absolutely no benefit for the kind 
of loop simulator I am writing. It is simply a waste of resources to 
implement the details. People are interested if their robot is turning 
left or right based on the current sensor value, not if there are 
interrupts thrown etc. They don't care to which bus the sensor is 
attached on the board. The problem is one abstraction higher than 
hardware. The reason to emulate the ARM Controller is that it is simpler 
to archive then to port the robot's operating system. This works pretty 
nice so far.

2. It makes no sense to me to emulate an I2C bus device with a made up 
protocol. This is somewhere between modeling all hardware and doing a 
paravirtualization. On one hand I could not do a pass through to the 
real hardware because their protocols are not compatible (made up vs. 
real world, complex protocol). On the other hand I have no benefit from 
the I2C emulation over an abstract communication mechanism, but the 
performance drops.

3. I do not circumvent the GPL! The whole software in the loop simulator 
is itself GPL Software. The reason I emulate the sensor values outside 
of qemu is simple. This is exactly what happens in the real world. The 
MCU or even the sensors do not know what values they read. This is 
decided by the environment. In the simulator this is archived by a 
complex environment simulation that has nothing to do with qemu and will 
never be part of it, no matter what license is involved.

4. Now, thanks to the help on this list I know there is a the "-chardev" 
functionality in qemu that basically archives what I did by hand using 
pipes. Now my idea is to port my own "proprietary" implementation to 
"the qemu way" - chardevs. You said you think it is a bad idea to build 
a device that directly translates I/O memory access to a chardev. I 
still don't understand why. Is this all about legal issues or is there a 
technical reason?

>> Could you point me to the code where the chardev devices are defined in
>> qemu?
I found examples in hw/char.

Regards
Alexander

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

[Paolo Bonzini]

Il 15/07/2014 20:55, Alexander Graf ha scritto:
> 3. I do not circumvent the GPL!   The whole software in the loop simulator
> is itself GPL Software. The reason I emulate the sensor values outside
> of qemu is simple. This is exactly what happens in the real world. The
> MCU or even the sensors do not know what values they read. This is
> decided by the environment. In the simulator this is archived by a
> complex environment simulation that has nothing to do with qemu and will
> never be part of it, no matter what license is involved.

Understood.  I didn't mean you were going to circumvent the GPL, just 
that a lot of justification is required for interfaces that allow doing 
that.

BTW, sorry for the confusion.  There is another frequent contributor to 
QEMU with the same name as yours.  I only noticed now that the email 
address is different.

> 4. Now, thanks to the help on this list I know there is a the "-chardev"
> functionality in qemu that basically archives what I did by hand using
> pipes. Now my idea is to port my own "proprietary" implementation to
> "the qemu way" - chardevs. You said you think it is a bad idea to build
> a device that directly translates I/O memory access to a chardev. I
> still don't understand why. Is this all about legal issues or is there a
> technical reason?
>
>>> Could you point me to the code where the chardev devices are defined in
>>> qemu?
> I found examples in hw/char.

I think that there are two other ways to do it.

1) You can look at hw/misc/tmp105.c and tests/tmp105-test.c for 
examples.  This is an I2C device, but the suggestion has nothing to do 
with I2C.

QEMU has an object model and an interface for outside devices to 
interact with the object model.  The command you need is qom-set.

Your MMIO device can expose properties like tmp105.c does with its 
"temperature" property.  The relevant code is:

static void tmp105_get_temperature(Object *obj, Visitor *v, void *opaque,
                                    const char *name, Error **errp)
{
     TMP105State *s = TMP105(obj);
     int64_t value = s->temperature * 1000 / 256;

     visit_type_int(v, &value, name, errp);
}

static void tmp105_set_temperature(Object *obj, Visitor *v,
                                    void *opaque,
                                    const char *name, Error **errp)
{
     TMP105State *s = TMP105(obj);
     Error *local_err = NULL;
     int64_t temp;

     visit_type_int(v, &temp, name, &local_err);
     if (local_err) {
         error_propagate(errp, local_err);
         return;
     }
     if (temp >= 128000 || temp < -128000) {
         error_setg(errp, "value %" PRId64 ".%03" PRIu64
                    " °C is out of range",
                    temp / 1000, temp % 1000);
         return;
     }

     s->temperature = (int16_t) (temp * 256 / 1000);


     tmp105_alarm_update(s);
}

static void tmp105_initfn(Object *obj)
{
     object_property_add(obj, "temperature", "int",
                         tmp105_get_temperature,
                         tmp105_set_temperature, NULL, NULL, NULL);
}


Here, the temperature is passed in 1/1000th of a °C (e.g. 20000 = 20 °C) 
and the device reads it in 1/256th of a °C (e.g. 20 °C reads as 0x1400).

You can give the device a QOM name like this:

     object_property_add_child(qdev_get_machine(), "mmio-interface",
                               OBJECT(mmio_interface), NULL);

between the call to qdev_create and the one to qdev_init_nofail.  If you 
are using sysbus_create_simple or sysbus_create_varargs, you will have 
to use the lower-level functions instead.

Then, in the QEMU invocation you can create a socket like this:

    ... -qmp unix:/tmp/unix.sock,server,nowait

on the command line and a single process will be able to connect to 
/tmp/unix.sock and send commands.  The first command must be

   { 'execute': 'qmp_capabilities' }

Then the actual accesses will look like this:

     { 'execute': 'qom-get', 'arguments': {
       'path': 'mmio-interface', 'property': 'temperature' } }
     { 'execute': 'qom-set', 'arguments': {
       'path': 'mmio-interface', 'property': 'temperature',
       'value': 20000 } }



2) Another possibility is to just place the sensor and actuator data in 
normal RAM.  You can use the test probe functionality ("qtest") to 
access it and read/write it while the guest is running.  It looks like this:

     ... -qtest unix:/tmp/unix.sock,server,nowait -machine accel=tcg

and it requires no glue code like the above object_property_*.  The 
protocol is very simple and documented in qtest.c.

Getting the next simulation tick is a bit more complicated, but 
possible.  If the above works out for you, and you can point us to some 
code, it will be easier to explain it.

Paolo

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

[Alexander Graf]

On 07/15/2014 10:09 PM, Paolo Bonzini wrote:
> BTW, sorry for the confusion.  There is another frequent contributor to
> QEMU with the same name as yours.  I only noticed now that the email
> address is different.

Oh right I noticed that; should have said something.

>> 4. Now, thanks to the help on this list I know there is a the "-chardev"
>> functionality in qemu that basically archives what I did by hand using
>> pipes. Now my idea is to port my own "proprietary" implementation to
>> "the qemu way" - chardevs. You said you think it is a bad idea to build
>> a device that directly translates I/O memory access to a chardev. I
>> still don't understand why. Is this all about legal issues or is there a
>> technical reason?

> I think that there are two other ways to do it.

And what about the chardev way? Your silence in this regard is 
misterious ;-)
>
> 1) [...]
> 2) [...]

Thanks a lot for your suggestions. I will play a bit and come back when 
I have some code to show.

Alexander

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

[Paolo Bonzini]

Il 16/07/2014 10:40, Alexander Graf ha scritto:
>>>
>
>> I think that there are two other ways to do it.
>
> And what about the chardev way? Your silence in this regard is
> misterious ;-)

The main problem with chardevs is that they are completely asynchronous. 
  So they may not be a good match for your use case.

(In fact, this is a problem for the i2c-over-chardev and especially 
spi-over-chardev ideas I shot out yesterday.  For i2c-over-chardev one 
could add support to clock stretching in QEMU, but SPI is entirely 
synchronous).

Note that -qmp and -qtest both use chardevs internally to connect the 
external program with QEMU.

Paolo

>>
>> 1) [...]
>> 2) [...]
>
> Thanks a lot for your suggestions. I will play a bit and come back when
> I have some code to show.