Hello Peter,
On Tuesday 10 of December 2024 11:08:53 Peter Maydell wrote:
> On Mon, 9 Dec 2024 at 23:33, Pavel Pisa <p...@fel.cvut.cz> wrote:
> > our CTU CAN FD IP core is used on many FPGA platforms
> > and has been even tapeout on some other university
> > and even prototypes of the massive production chips
> > (support for that organized by our former student
> > in his company).
> >
> > But actual QEMU emulation targets only PCI/PCIe mapping in
> >
> > hw/net/can/ctucan_pci.c
> >
> > of the core in
> >
> > hw/net/can/ctucan_core.c
> >
> > I would like to add support to map the core at fixed position for
> > SoCs and command line controlled location for FPGA targets.
>
> Command line instantiation of devices at command line
> controlled addresses and with command line connection
> of IRQ lines is basically something we do not
> currently support. There is some prototype/design work
> going on about generic "create a machine from
> the command line" handling, which would inevitably
> involve allowing the user to specify addresses and IRQ
> lines. But I don't really want to see ad-hoc device-specific
> additions of small parts of similar functionality.
>
> If there's a SoC that QEMU models that has this CAN
> controller, then it's the SoC model (written in C)
> that defines where it is mapped in memory and what
> IRQ lines it is wired up to.
There should be such SoC in some time even in public.
I understand that in such case the mapping should
be part of its support.
But main area of the CTU CAN FD IP core use
are FPGAs for now, Xilinx Zynq and above, Intel/Altera
SoC+FPGAs, actual next target to test is Microchip
PolarFire on BeagleV-Fire which allows to develop
and test driver for Linux, NuttX and RTEMS on the single
chip. And it would be great if there is option to
run that on CI and have (still simplified - no bitrate
miscmatch check etc) model for SW development with QEMU.
And CTU CAN FD does not belong to the core Zynq or PolarFire
support in such cases. So even this actual solution is usable
in such cases. But as I have expected, it is not so welcomed
in mainline... which is why I attempt to find what can be done.
Do you consider the the proposed trick (target object specified by
"irqctrl" parameter on commad line and then resolved by
object_resolve_path_at()) as unacceptable for mainline?
Another problem is if the qemu_irq can be copied in ctucan_mm_realize.
I have tried even another solution where chip core kept pointer
to qemu_irq in the bus integration wrapper (PCI/PCIe and platform).
But even for mainlined PCI/PCIe CTU CAN FD support I would like
to update support to provide real "or" operation between IRQs
outputs from individual controllers to PCI/PCIe interrupt link.
So in this case, I would be happy to hear if I can reuse
qemu_irq and some routing or if I should define own mechanism
to activate callback provided by the bus integration wrapper
from the core emulation code. But may it be some pin logic
already implemented in QEMU can be used there.
Best wishes,
Pavel
PS: does somebody have some experience, information for
use of "16c3:abcd" DWC_usb3 / PCIe bridge on i.MX6 Sabre
Litte, I have sent plea for help two months ago without
any respone and it would help our another CAN controller
development project, iMX6 FlexCAN support.
--
Pavel Pisa
phone: +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal: http://cmp.felk.cvut.cz/~pisa
social: https://social.kernel.org/ppisa
projects: https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
