Outstanding Qemu Patches - CAN SJA1000 and Data Acquisition PCI CARD

[Pavel Pisa]

On Tuesday 28 of October 2014 23:31:32 Joel Sherrill wrote:
> Hi
>
> I am back from the GSoC mentor summit and Chris will be home
> soon I guess. I tracked down the qemu project person who was
> there. Once again, he wasn't THE right person to address the
> patches we care about not getting in but he gave some hints.
>
> First I need a list of patches with descriptions.
>
> Hopefully I can push this and get the patches we care about
> upstreamed.
>
> Thanks.

Hello Joel,

we have two directions of patches which worth to consider.
I have done their merge above QEMU-2.1 release, branch
"merged-2.1"

https://github.com/CTU-IIG/qemu

The CAB bus related work is available on branch "can-pci"

https://github.com/CTU-IIG/qemu/tree/can-pci

commit 9dab36a04f9e62e4017921635a3e4f31421e2739
Author: Pavel Pisa <pisa at cmp.felk.cvut.cz>
Date:   Tue Aug 5 18:59:05 2014 +0200

    CAN bus simple SJA1000 PCI card emulation for QEMU

    The work is based on Jin Yang GSoC 2013 work funded
    by Google and mentored in frame of RTEMS project GSoC
    slot donated to QEMU.

    Rewritten for QEMU-2.0+ versions and architecture cleanup
    by Pavel Pisa (Czech Technical University in Prague).

    The core SJA1000 support is independent of provided
    PCI board. The simple core CAN bus infrastructure
    is independent as well.

    Connection to the real host CAN bus network through
    SocketCAN network interface is available for Linux
    host system as well.

    Signed-off-by: Pavel Pisa <pisa at cmp.felk.cvut.cz>

commit 68d16652f760125547e5d3724e146c50c2f4e345
Author: Pavel Pisa <pisa at cmp.felk.cvut.cz>
Date:   Tue Aug 5 18:56:49 2014 +0200

    CAN bus Kvaser PCI CAN-S (single SJA1000 channel) emulation added.

    Signed-off-by: Pavel Pisa <pisa at cmp.felk.cvut.cz>

The code has been separated from QEMU networking directory
because there was no suggestion which would allows better
integration with QEMU networking code and in general CAN
bus is quite different from common ETHERNET/packet based
networks. So solution is now fully separated to not clash
and mix with other QEMU subsystems and actual implementation
is quite minimal yet usable for CAN drivers and infrastructure
testing. If there is some reasonable advice/idea how to use
different way of integration I would look at is as my RTEMS
and QEMU enthusiasm time allows.

The other project is emulation of PCI data acquisition card
in QEMU - mf624. It not common hardware like Advantech etc.
but we have many of these cards at department so we can test
code on real and virtual HW. We have UIO and Comedi Linux drivers
for this hardware as well as we have tested full Matlab/Simulink
Linux RT code generation for UIO and Comedi based solution.
It would be interesting to have all these for RTEMS as well.
I.e. combined with with this year GSoC for GPIO and other
control peripherals drivers for RTEMS. The card hardware
emulation is implemented in branch "mf624"

https://github.com/CTU-IIG/qemu/tree/mf624

commit 3eb97722573dd6f5a34450a02318726b354eedf4
Author: Pavel Pisa <pisa at cmp.felk.cvut.cz>
Date:   Tue Aug 5 18:07:56 2014 +0200

    Support for Humusoft MF624 data acquisition card.

    More information about Linux and QEMU support for these cards

      http://rtime.felk.cvut.cz/hw/index.php/Humusoft_MF6xx

    Producer pages with card documentation

      http://www.humusoft.cz/produkty/datacq/mf624/

    Signed-off-by: Pavel Pisa <pisa at cmp.felk.cvut.cz>

The squashed single patch with HW emulation implementation is
result of long term activities to have testbed for our applications
implemented. Most work done by Rostislav Lisovy <lisovy at gmail.com>.
Actual implementation uses simple TCP socket to access
and update HW state from host side system. I have seen that some
generic layer for GPIO is already implemented in later QEMU
sources. I am not sure about analog signals infrastructure
for ADC and DAC channels. If there is wiliness to discuss
how such things could be modelled in future in QEMU, we would
be happy. But I have fear that fundamental features to make
QEMU usable for control and real-time systems development
are quite low on the importance scale, because virtual
servers and desktops are probably paying most of QEMU work.

Anyway, each input to help these activities and or QEMU
to provide better testbed for control systems is welcomed.

Best wishes,

                Pavel