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 <p...@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 <p...@cmp.felk.cvut.cz> commit 68d16652f760125547e5d3724e146c50c2f4e345 Author: Pavel Pisa <p...@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 <p...@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 <p...@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 <p...@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 <lis...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
