|
From: | Paolo Bonzini |
Subject: | Re: [Qemu-devel] hw/arm: add Lego NXT board |
Date: | Tue, 15 Jul 2014 12:53:17 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |