On Thu, Feb 24, 2022 at 6:39 AM Ben Dooks <ben.dooks@codethink.co.uk> wrote:
On 24/02/2022 11:05, Peter Maydell wrote:
On Thu, 24 Feb 2022 at 10:53, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
I have been trying to get qom-get/qom-set scripts working to make an
virtual GPIO device on qemu-system-x86_64. I have a working TMP105
and I can see the MAX7310 being instantiated with the relevant Linux
devices showing up (i2c, gpio).
I can read the sensor from QEmu console:
(qemu) qom-get /machine/peripheral/sensor temperature
20000
(qemu) qom-set /machine/peripheral/sensor temperature 19000
(qemu) qom-get /machine/peripheral/sensor temperature
19000
When trying to get or set anything from the GPIO chip it doesn't
seem to be working. How do I get this working, I haven't found
any useful reference online and need some help:
(qemu) qom-set /machine/peripheral/gpio unnamed-gpio-out[0] 0
Error: Device '0' not found
(qemu) qom-set /machine/peripheral/gpio unnamed-gpio-in[0] 0
Error: Insufficient permission to perform this operation
The 'unnamed-gpio-out/in' properties are part of the mechanism by
which a QEMU machine model can connect up GPIO lines of devices it
creates (for instance, it might connect a device's outbound GPIO
line to a GPIO controller). They appear in the monitor
qom-set/qom-get APIs because they use the same underlying
infrastructure as user-settable properties, but you can't do
anything useful with them on the command line.
If you need to wire up a device's GPIO lines, you need to do
it in C code as part of the QEMU machine model implementation.
Put another way,
-device max7310,id=gpio,address=0x20
will work fine for "put a gpio controller at this i2c address,
so that guests that expect to be able to talk to one there
don't crash". You can't however actually wire up any of that
controller's GPIO lines to anything (emulated LEDs, other
devices, etc, etc).
Ok, thanks.
I was really trying to do something simple. I want to add the
GPIO chip and just control the lines from an external script
as part of a testing environment where the test framework can
change a GPIO value and the configuration in the machine will
notice this and take appropriate actions.
Is it worth adding some mechanism to allow the command line to
specify how gpios are created, or have an option to just export
all the GPIO lines as generic GPIOs? I'll have to go see how
much effort it would be to make our own machine file.
I am also having issues with both sensor and the gpio via the
qom-set, as so:
$ sudo ./scripts/qmp/qom-set --socket ~/qmp.sock
/machine/peripheral/sensor.temperature 20200
ExecuteError: Invalid parameter type for 'temperature', expected: integer
Task was destroyed but it is pending!
Is this also a known issue?
I'm not sure what's going on there: it sounds like something
is confused about types. I've cc'd the python qmp scripts maintainer.
Howdy. The qom-set and qom-get tools have been around for quite a
while longer than I have been taking care of them, and I wasn't sure
if anyone was actually using them...
They *do* have a defect where they assume anything you enter is a
string and they send it that way over the wire. If the argument you
are sending actually requires an integer, it's going to fail. I had a
discussion recently on how we might be able to fix this, but since QOM
data is ... semi-opaque and incomplete at times, there's no real way
to know the correct type in advance.
If it would help people out, I could change the way the scripts work
to place the burden on the human user, i.e.
qom-set \"20200\"
qom-set 20200
would become explicitly different invocations. I really genuinely have
no clue if anyone is relying on this script though, so I've been
afraid to really do much with it. Maybe breaking some users of this
script in order to prevent new users from learning it doesn't really
work is a fine trade-off, though.