Re: QEMU CAN-FD emulation

Re: QEMU CAN-FD emulation

[Pavel Pisa]

Dear Sukreet Pal,

On Tuesday 18 of January 2022 12:41:35 sukreet.pal@st.ovgu.de wrote:
> Yes, we can push the conversation in qemu mailing list.

Great, may be there is some other input from the list.

Recapitulation:

Sukreet Pal want to use CAN emulation included
in QEMU to test some CAN related software build
for ARM. At this moment, CAN emulation
is available for systems which are equipped by PCI
and for some platform devices on Xilinx

  https://github.com/qemu/qemu/blob/stable-6.1/docs/can.txt

For generic ARM system PCI and SJA1000 driver should
be usable out of the box when appropriate kernel is used.
When I have developed with my students and test and maintain
CAN (SJA1000 and CTU CAN FD) emulation support I use
combination of ARM1176 and VersatilePB for testing.

This setup works for me

Host side (laptop with Debian and without real CAN hardware)

  modprobe can-raw
  modprobe vcan
  ip link add dev can0 type vcan
  ip link set can0 up

The QEMU invoked

qemu-system-arm -cpu arm1176 -m 256 -M versatilepb \
      -kernel kernel-qemu-arm1176-versatilepb \
      -initrd ramdisk.cpio \
      -hda rpi-wheezy-overlay \
      -append "root=/dev/ram console=ttyAMA0" \
      -object can-bus,id=canbus0 \
      -object can-host-socketcan,if=can0,canbus=canbus0,id=canbus0-socketcan \
      -device kvaser_pci,canbus=canbus0 \
      -virtfs local,path=shareddir,security_model=none,mount_tag=shareddir \
      -nographic \

I have some own minimal busybox based initial ramdisk to test QEMU
and kernel from it.

On Monday 17 of January 2022 17:31:32 Pavel Pisa wrote:
> If you can reach shell prompt in the target system
> you should check that Kvaser CAN controller is seen
> on PCI bus.
>
> Try
>
>   lspci -nn
>
> You should see there 10e8:8406. If you do not have lspci
> availabel in the target system, then try
>
>   cat /proc/bus/pci/devices
>
> There should be line
>
>   00xx    10e88406        5e                  1401                    1481
>
> Check that your ARM kernel build includes kvaser_pci driver
> as built in or as the module. I have it as a module.
>
> So my lsmod list
>
>   Module                  Size  Used by    Not tainted
>   kvaser_pci              2332  0
>   sja1000                 6023  1 kvaser_pci
>   can_raw                 6112  0
>   can_dev                 8289  1 sja1000
>   can                    26342  1 can_raw
>   ...

On Tuesday 18 of January 2022 11:08:32 sukreet.pal@st.ovgu.de wrote:
> # lspci -nn
> 00:0c.0 Class 0100: 1000:0012
>
> / # cat /proc/bus/pci/devices
> 0060	10000012	5d	            1001	        50002000	        50000000
>              0	               0	               0	               0
>          100	             400	            2000	               0
>          0	               0	               0	sym53c8xx
>

So it seems that device is not visible on the PCI bus by the kernel.

Suggestion to list QEMU PCI bus devices from QEMU monitor

On Tuesday 18 of January 2022 11:42:49 Pavel Pisa wrote:
> For QEMU monitor access see
>  
> 
https://serverfault.com/questions/587189/how-to-list-all-devices-emulated-in-a-qemu-virtual-machine
>
> Use
>
>   info pci
>
> You should see in the list
>
>     Bus  0, device  XX, function 0:
>     Class 65280: PCI device 10e8:8406
>       PCI subsystem 1af4:1100
>       IRQ 94, pin A
>       BAR0: I/O at 0x1400 [0x147f].
>       BAR1: I/O at 0x1480 [0x14ff].
>       BAR2: I/O at 0x1820 [0x1827].
>       id ""
>
> If this is not in the list then kernel cannot see the device either.

On Tuesday 18 of January 2022 12:41:35 sukreet.pal@st.ovgu.de wrote:
> (qemu) info pci
>    Bus  0, device  11, function 0:
>      Class 2880: PCI device 10ee:0300
>        PCI subsystem 1af4:1100
>        id ""
>    Bus  0, device  12, function 0:
>      SCSI controller: PCI device 1000:0012
>        PCI subsystem 0000:1000
>        IRQ 93.
>        BAR0: I/O at 0x1000 [0x10ff].
>        BAR1: 32 bit memory at 0x50002000 [0x500023ff].
>        BAR2: 32 bit memory at 0x50000000 [0x50001fff].
>        id ""
>    Bus  0, device  13, function 0:
>      Class 65280: PCI device 10e8:8406
>        PCI subsystem 1af4:1100
>        IRQ 94.
>        BAR0: I/O at 0xffffffffffffffff [0x007e].
>        BAR1: I/O at 0xffffffffffffffff [0x007e].
>        BAR2: I/O at 0xffffffffffffffff [0x0006].
>        id ""
>
> I think the kernal can see the devices.

It seems that QEMU report device on the bus but
the kernel does not list device in /proc/bus/pci/devices

> > What is version of your QEMU?
>
> QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.19)
> Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project
> developers (it's the default ubuntu 20.04 qemu version)

In my development repo the last used is

QEMU emulator version 6.0.91 (v6.1.0-rc1-3-g1560ab766e)
Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers

But I have retested with Debian old stable distribution
version

QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u8)
Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers

and emulation works.

On the report it is strange that device is not seen in the kernel
proc list. It is independent of driver availability.

The strange is even BAR report
  BAR0: I/O at 0xffffffffffffffff [0x007e].  ...
Mine
  BAR0: I/O at 0x1400 [0x147f]. ...

But I expect that BAR FFF value is caused by
unconfigured address. Strange is that the last
bit in the bracket is 0. The BAR fixed
part should respect that it is IO device.

I have seen some warning that PCI I/O devices
mapping is not supported/emulated on VersatilePB.
I have no problems with Kvaser emulation on that
platform with all tested QEMU builds from I think
2.x days.

Test of the other actually supported SJA1000 devices
would not help probably because mioe3680 and pcm3680
are also I/O mapped.

Option is to test our CTU CAN FD which is memory
region mapped

 -device ctucan_pci,canbus0=canbus0-bus,canbus1=canbus0-bus

But t is necessary to build driver for given kernel.
It is available in the repo and has been recently
updated to the required style  

  https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core

(I hope to find time and help for mainlining soon).

Best wishes,

                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa@cmp.felk.cvut.cz
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    university: http://dce.fel.cvut.cz/
    personal:   http://cmp.felk.cvut.cz/~pisa
    projects:   https://www.openhub.net/accounts/ppisa
    CAN related:http://canbus.pages.fel.cvut.cz/
    Open Technologies Research Education and Exchange Services
    https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home