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

[Paolo Bonzini <pbonzini@redhat.com>]

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