qemu-devel
[Top][All Lists]
Advanced

[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: Tue, 15 Jul 2014 20:55:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]