qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Writing a CAN driver for QEMU


From: Pavel Pisa
Subject: Re: [Qemu-devel] Writing a CAN driver for QEMU
Date: Sun, 19 May 2013 02:44:01 +0200
User-agent: KMail/1.9.9

Hello All,

On Saturday 18 May 2013 23:23:28 Rempel, Cynthia wrote:
> >> Would following the guidance in:
> >> http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg00842.html
> >> increase the probability the [CAN] device simulation would be committed
> >> to qemu?
> >
> >Yes, I think so.
> >
> >Here is also some help which shows the fundamental
> >requirements for new contributions:
> >
> >http://wiki.qemu.org/Contribute/SubmitAPatch
>
> Thank you! This is very helpful :)
>
> >Are you planning to emulate an existing CAN controller,
> >or do you want to design a new virtual CAN controller
> >from scratch?
>
> If feasible, we would prefer to emulate a CAN controller that has a LinCan
> port, so that we have a "known good" software configuration to work with...
>
> http://ortcan.git.sourceforge.net/git/gitweb.cgi?p=ortcan/lincan;a=tree;f=l
>incan/src
>
> We would want to have the student write an emulation for the CAN portion of
> one (1) of the CAN controllers... We will want to be able to hook it into
> qemu-system-arm... which of these controllers would it be more feasible to
> write an emulation for?
>
> ADLINK 7841 card
> AIM104CAN PC/104 card
> BFAD can
> C_CAN Bosch
> CAN104 PC/104
> Kontron EB8245
> EMS-WUENSCHE CPC-PCI
> CAN/PCI-200
> PCI/PMC 266 card
> PCAN-PC/104
> sja1000 CAN
> SH7760 HCAN2
> HMS30c7202 C_CAN
> i82527 CAN
> IXXAT iPC-I 165
> KVASER PCIcan
> M437 PC/104
> MPC5200 MSCAN
> PC-I03
> PCAN-PCI
> PCCCAN board
> PCM-3680 PC/104
> MX1_DIS1
> PIP5,PIP6,PIP7 and PIP8
> SJA1000 chip PeliCanCAN
> SSV board
> TS-7KV multifunction card
> Unicontrols PCAN
>
> We really appreciate all the help!

The question is what is the reasonable controller to emulate.
Today, Bosch IP core C_CAN is quite often integrated in devices.
But its windowed message objects access is nightmare.

Some clean simple CAN controller (like FreeScale MSCAN) would
be much simpler to implement, but this is not PCI connected
on any target (mos probably).

So if we speak about chip with broad availability then SJA1000 is
the choice. It complicates things by only 8-bit registers access
and old non-PeliCAN mode for compatibility. But it can be even ignored.
Then it is single Rx object + FIFO based which simplifies implementation.

There exists many PCI boards with SJA1000 behind different PCI/local
buss bridges. Some are quite bizare with strange edge triggered
IRQs routing and combining which requires to be extra carefull
for IRQ processing on driver side.

The board with clean simple design and level interrupts are Kvaser
PCIcan-S, PCIcan-D, PCIcan-Q.
The actual naming is little different but I expect that it is same HW
PCIcan HS, PCIcan HS/HS, PCIcanx 4xHS

  http://www.kvaser.com/en/products/can/pci.html

We have more these cards so we can check even on real HW.

I have found manual there for example

http://simlab.dyndns.org:9000/AllegroHandWiki/images/c/c5/Kvaser_PCIcan_Hardware_Reference_Manual.pdf

So it is good choice for QEMU and Linux (and even for RTEMS if more 
architectures should be supported). The PCIcan-Q has even nice feature
to connect and terminate selected channels directly on board so no external
componets/cables are not required for simple testing.

On the other hand some FPGA design like Gailser GRCAN, MSCAN or FlexCAN
can be simpler when we consider non PCI one system.

By the way, how is it with future possible integration ofMBED 
(http://mbed.org/nxp/lpc1768/) board QEMU support
(https://github.com/gdrane/MBEDSimulator.git).
It LPC17xx is an another candidate.

We should discuss the QEMU CAN controller emulation selection
on address@hidden mailing list.

I have information that one big carmaker in cooperation with one
big chip maker has full CAN controller and network model including
bit-timing implemented. But I do not know more and it is possible
that their implementation is to complex for reuse in QEMU (and probly
even not publicable).

But we should discuss on which chip to focuss with SocketCAN
maintainers on linux-can for sure.

Best wishes

                Pavel Pisa
    e-mail:     address@hidden
    www:        http://cmp.felk.cvut.cz/~pisa
    university: http://dce.fel.cvut.cz/
    company:    http://www.pikron.com/



reply via email to

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