Changes between Version 69 and Version 70 of Developer/Simulators/QEMU/CANEmulation


Ignore:
Timestamp:
Sep 15, 2013, 6:50:39 AM (6 years ago)
Author:
Jinyang
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Developer/Simulators/QEMU/CANEmulation

    v69 v70  
    11= QEMU with CAN Emulation =
    22
    3 
    4 Actually this is a project of GSoC2013. At first I try to port a CAN driver LinCAN to RTEMS. But we don't have a common hardwate platform to test the driver, so how to test the driver become the most significant problem here. Finaly we decide to build a software environment to test the dirver. This environment is built using the open source machine emulator QEMU and SJA1000 is simulated to test the driver. For the sake of simplicity, we test it in Linux and use SocketCAN as a driver.
     3=  Introduce  =
     4
     5Actually this is a project of GSoC2013. At first I try to port a CAN driver LinCAN to RTEMS. But we don't have a common hardwate platform to test the driver, so how to test the driver become the most significant problem here. Finaly we decide to build a software environment to test the dirver. This environment is built using the open source machine emulator QEMU and SJA1000 is simulated to test the driver. For the sake of simplicity, we test it in Linux(as it's familiar) and use SocketCAN(as it's maintlined into Linux) as a driver.
     6
     7Also, we decide to use PCI CAN controller and simulate on x86 Linux platform . Since, PCI as a general standard is easy to extend and pci device can seperate from others. Then this PCI device can be used with x86, so QEMU (with KVM) would be much faster and use less resource than other platform such as ARM.
     8
    59=  Environment  =
    610
     11The OS will be Linux and the current CAN driver to test will be Socket CAN (as it's maintlined into Linux)
    712 *  Host: The host is Ubuntu-13.04 including the basic building tools and some other softwares.
    813 *  Guest: This is also a Linux environment which we build from scratch. The linux kernel is [https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.4.48.tar.bz2 Linux-3.4.48], the commands are statically compiled using [http://www.busybox.net/downloads/busybox-1.21.0.tar.bz2 Busybox-1.21.0] and also some other files including configure files, start scripts, etc.
     
    1116The best option is to implement that as simple device
    1217  -chardev can,id=sja1000,port=vcan0
    13   -device pci-can,chardev=sja1000
     18  -device pci-can,chardev=sja1000,model=SJA1000
    1419and use Linux mainlined SocketCAN API to connect virtual device to real CAN hardware (SocketCAN allows multiple applications access) or to SocketCAN Virtual CAN (vcan - TCP/IP lo equivalent). This is straightforward and would result in minimal overhead and latency.
    1520
    16 
    17 
    18 
    19 
    20 
    21 
    22 
    23 
    24 
    25 
    26 
    27 The OS will be Linux and the current CAN driver to test will be Socket CAN (as it's maintlined into Linux)=  Excerpts from the email chain  =
    28 
    29 '''Stefan Weil''': PCI (and USB if they were supported with LinCAN) CAN controller boards
    30 could also be used with x86, so QEMU (with KVM) would be much faster
    31 and use lessresources than an ARM system emulation.
    32 
    33 So one of the PCI controllers might be the best choice.
    34 
    35 Select one with good documentation, complete implementation (on the
    36 RTEMS / LinCAN side) and small source code (which is typically an
    37 indicator for the complexity - a large complex driver typically
    38 also needs a complex emulation in QEMU).=  Use Cases  =
    39 
    40 '''Paolo Bonzini and > Cynthia Rempel'''
    41 
    42 > we want to be able to verify a guest OS's CAN driver has been integrated
    43 
    44 > properly and is sending CAN packets...
    45 
    46 >
    47 
    48 > Perhaps along the lines of two calls:
    49 
    50 > qemu-system-arm -hda linux1.img -can student-implemented-device
    51 
    52 > qemu-system-arm -hda linux2.img -can student-implemented-device
    53 
    54 You would probably use either -net, or -netdev and -device (see
    55 docs/qdev-device-use.txt).
    56 
    57 > Then using a network protocol analyzer (such as Wireshark) with a custom
    58 
    59 > filter to recognize CAN packets,
    60 
    61 > OR
    62 
    63 > qemu-system-arm -hda linux1.img -can student-implemented-device
    64 
    65 > then attaching a real CAN device to the host computer and verifying that the
    66 
    67 > output is being recognized be real hardware.
    68 
    69 Is this CAN device just an Ethernet device?  QEMU does not support other
    70 link-level protocols.  Adding them would be possible and interesting,
    71 however it would add a bit to the complexity.
    72 
    73 > Whichever is more feasible to implement...
    74 
    75 Both would be the same.  In the first case, you'd probably use "-netdev
    76 socket" to share a virtual network between two virtual machines.  In the
    77 second, you would use something like "-netdev tap" (again assuming it's
    78 just an Ethernet device).
    79 =  Implementation  =
    80 
    81 '''Paulo B''':
    82 Ok, learnt a bit more...  You could probably implement this in two ways:
    83 1) "-netdev socket" would probably work as a CAN->UDP gateway;
    84 
    85 2)
    86 connecting to a virtual CAN interface in the host, created using
    87 SocketCAN (similar to "-netdev tap", e.g. "-netdev cantap").
    88 
    89 In the first case, it would probably be useful to write the matching
    90 UDP->CAN gateway program.
    91 
    92 In any case, you have to implement both the backend and the actual device.
    93 
    94 '''Stefan Weil''':
    95 I used TCP instead of UDP in a proprietary solution more than
    96 10 years ago.
    97 
    98 CAN devices are connected to CAN buses, so I had a CAN device
    99 emulation (on CAN API level, not on hardware level like with QEMU)
    100 and a CAN bus emulation.
    101 
    102 The CAN bus emulation was a TCP server process. It could simulate
    103 several CAN buses.
    104 
    105 Each CAN controller was a TCP client connected to the CAN bus emulation.
    106 
    107 The TCP clients sent CAN data packets (length, packet type and data)
    108 to the TCP server and received such packets from the server.
    109 They also exchanged control packets with the server (topology = which bus,
    110 data rate, CAN filter settings).
    111 
    112 The CAN bus emulation routed each received packet to other CAN controllers
    113 on the same bus (CAN is a broadcast protocol) and could also simulate
    114 error packets (for example when there was a mismatch of the data rates
    115 between sender and receiver). In debug mode, the bus emulation could
    116 also display the packets (raw data or CAN Open packets).
    117 
    118 Several CAN vendors provide bidirectional CAN-Ethernet gateways,
    119 but I don't know whether there is a standard for CAN-over-Ethernet.
    120 
    121 '''Andreas Färber''':
    122 Unfortunately that is out of date as far as the code goes (QOM is our
    123 successor to qdev), but it might serve as a good starting point.
    124 I emailed you my KVM Forum slides on QOM with a device skeleton to use
    125 as a starting point.
    126 
    127 One point I would like to point out is that QEMU devices don't simulate
    128 their hardware counterpart but instead only emulate them - that is, if
    129 you implement, e.g., a Freescale MPC5604B FlexCAN or Renesas RX62N RCAN
    130 controller you will deal with register accesses coming from the guest
    131 and their abstract concepts like mailboxes and objects rather than
    132 actual line-encodings. So if you want, you might get around some of the
    133 gory details by implementing the device using an abstract CANBus bus
    134 implementation (cf. PCIBus, I2CBus, etc.) and if necessary interfacing
    135 with whatever CAN API on the host directly; if you need to externalize
    136 this through a -chardev command line option for analysis, it probably
    137 requires some more work.
    138 
    139 '''Pavel Pisa''':
    140 1) I think that for Linux the best option is to implement that as simple
    141 device
    142   -device can-kvasser-pcican-q
    143 or
    144   -device pcican,model=kvasser-pcican-q
    145 and use Linux mainlined SocketCAN API to connect virtual device
    146 to real CAN hardware (SocketCAN allows multiple applications access)
    147 or to SocketCAN Virtual CAN (vcan - TCP/IP lo equivalent).
    148 This is straightforward and would result in minimal overhead and latency.
    149 
    150 2) If the portability is a problem, then we can create UDP socket
    151 and use it send CAN messages as packets (but it is newer able to
    152 model and pas over real CAN bus behavior, i.e. there are no silently
    153 lost messages on CAN side due to ACK). We have done prototype
    154 of SocketCAN to Ethernet gateway (in user-space and in Linux kernel)
    155 on contract with SocketCAN project. So we can offer some part of
    156 the code for reuse. Code is open/GPLed.
    157 
    158 3) The option is to provide both above method or even pull in OrtCAN
    159 VCA (virtual can API) library which can route CAN messages to SocketCAN,
    160 LinCAN and possibly other targets.
    161 
    162 Problem is that there is knowledge but amount of work could easily
    163 exceed RTEMS GSoC resources. So I would incline personally to 1).
    164 But opinions, help, documentation etc are welcomed.
    165 
    166 ''' Andreas Farber''':
    167 While using a model property is not wrong per se, "can" seems too
    168 generic as type name, since it needs to inherit from a particular base
    169 class such as PCIDevice. QOM types can be made abstract to share code
    170 between device implementations to the same effect, e.g. PCIHostState.
    171 =  Submitting a Patch to Qemu  =
    172 
    173 [http://wiki.qemu.org/Contribute/SubmitAPatch fundamental requirements for new contributions]:
    174 
    175 
    176 
    177 
    178 
    179 
    180 
    181 
    182 
    183 
     21The above options just connect the ''can'' backend to the PCI-CAN device. Just explain the options simply.
     22 *  '''-chardev can,id=sja1000,port=vcan0'''  specify which backend should we open, here can. ''id'' used for the -device option; ''port'' which interface should we open, we use virtual socketcan device here.
     23 *  '''-device pci-can,chardev=sja1000,model=SJA1000''' we use pci-can device. ''chardev'' the value '''MUST''' equal to the id specified in chardev option; ''model'' is an optional parameter, default value is SJA1000 and we only support SJA1000 now.
    18424=  Step 1: Building a Minimal Linux Environment in Qemu  =
    18525