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

[Alexander Graf <graf@campus.tu-berlin.de>]

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