"4.14+: Both versions of qemu (as-is and interrupts reverted) work fine"

Hm. I really wonder how it can be possible that Linux works with the
interrupt vectors reversed, though to be fair I have not looked at the
Linux i.MX6 ENET driver code. I suppose it's possible that the driver is
binding the same interrupt service routine to both interrupt vectors. If
so, then it works by accident. :)

I think U-Boot uses polling so it wouldn't care if the interrupt vectors
are wrong.

We have several SabreLite boards in house. We also have NXP Sabre SD
reference boards which use the same i.MX6Q SoC and the exact same
ethernet driver with the same interrupt configuration. I have always
used VxWorks with them rather than Linux, and I can say for a fact that
the VxWorks ENET driver only binds an ISR to vector 150 (118) (VxWorks
doesn't currently support the IEEE 1588 feature with this interface so
it never uses vector 151) and it works as expected -- network interrupt
events are indeed received via vector 150.

The same VxWorks image that works with real hardware does not work with
QEMU unless I fix the vectors in fsl-imx6.h.

In short, both the hardware and the manual seem to agree. QEMU is doing
it wrong. :)

Also, the errata sheet for the i.MX6 is here:


Apparently erratum 6687 is related to power management and wakeup
events. I'm not sure how that factors in to how Linux behaves.

You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

  Ethernet interrupt vectors for sabrelite machine are defined backwards

Status in QEMU:

Bug description:
  The sabrelite machine model used by qemu-system-arm is based on the
  Freescale/NXP i.MX6Q processor. This SoC has an on-board ethernet
  controller which is supported in QEMU using the imx_fec.c module
  (actually called imx.enet for this model.)

  The include/hw/arm/fsm-imx6.h file defines the interrupt vectors for
  the imx.enet device like this:

  #define FSL_IMX6_ENET_MAC_1588_IRQ 118
  #define FSL_IMX6_ENET_MAC_IRQ 119

  However, this is backwards. The reference manual for the i.MX6D/Q
  devices can be found here:


  On page 225, in Table 3-1. ARM Cortex A9 domain interrupt summary, it
  shows the following:

  150 ENET
  MAC 0 IRQ, Logical OR of:
  MAC 0 Periodic Timer Overflow
  MAC 0 Time Stamp Available
  MAC 0 Time Stamp Available
  MAC 0 Time Stamp Available
  MAC 0 Payload Receive Error
  MAC 0 Transmit FIFO Underrun
  MAC 0 Collision Retry Limit
  MAC 0 Late Collision
  MAC 0 Ethernet Bus Error
  MAC 0 MII Data Transfer Done
  MAC 0 Receive Buffer Done
  MAC 0 Receive Frame Done
  MAC 0 Transmit Buffer Done
  MAC 0 Transmit Frame Done
  MAC 0 Graceful Stop
  MAC 0 Babbling Transmit Error
  MAC 0 Babbling Receive Error
  MAC 0 Wakeup Request [synchronous]

  151 ENET
  MAC 0 1588 Timer interrupt [synchronous] request

  150 - 32 == 118
  151 - 32 == 119

  In other words, the vector definitions in the fsl-imx6.h file are
  reversed. The correct definition is:

  #define FSL_IMX6_ENET_MAC_IRQ 118
  #define FSL_IMX6_ENET_MAC_1588_IRQ 119

  I tested the sabrelite simulation using VxWorks 7 (which supports the
  SabreLite board) and found that while I was able to send and receive
  packet data via the simulated ethernet interface, the VxWorks i.MX6
  ethernet driver failed to receive any interrupts. When I corrected the
  interrupt vector definitions as shown above and recompiled QEMU,
  everything worked as expected. I was able to exchange ICMP packets
  with the simulated target and telnet to/from the VxWorks instance
  running in the virtual machine. I used the tap interface for this.

  As a workaround I was also able to make the ethernet work by modifying
  the VxWorks imx6q-sabrelite.dts file to change the ethernet interrupt
  property from 150 to 151.

  This problem was observed with the following environment:

  Host: FreeBSD/amd64 11.1-RELEASE
  QEMU version: 2.11.0 and 2.11.1 built from source code

To manage notifications about this bug go to:

Reply via email to