SPI/QSPI slave under Linux


I have a very similar requirement to this question, except I’m interfacing with an external MCU instead of an FPGA. As with the linked question, the MCU produces a high volume of measurement data, which it then needs to send to the Apalis.

The aim is to use either SPI or QSPI for this interface. I’m using a UART interface between the MCU and the Apalis for low-speed data exchange (configuration data, commands, etc.), so the SPI/QSPI interface can be used solely for the high volume measurement data. This also means the SPI/QSPI interface can be unidirectional.

The issue I’m facing is regarding the Master/Slave configuration of the interface. It makes sense (as pointed out in the linked question) for the MCU to be the Master, as it is the only device sending data. However, I understand that while supported on the later kernels, using Linux as a high-speed SPI Slave is an unusual use case. In addition to this, the MCU only supports QSPI Master mode, so if I were to use QSPI (which would be ideal given the increased bits per clock), I would have to implement a QSPI Slave process under Linux.

As such, here are my perceived options, for which I’d very much appreciate some input and/or recommendation:

  1. MCU as SPI Master and Linux as SPI Slave. Limited to 40Mbit/s (as per Apalis iMX8 datasheet).
  2. MCU as SPI Slave and Linux as SPI Master. Option 1: additional ‘data ready’ line output from MCU which initiates a transfer from the Linux Master when the MCU toggles the line. Limited to 60Mbit/s (as per Apalis iMX8 datasheet).
  3. MCU as SPI Slave and Linux as SPI Master. Option 2: additional ‘data ready’ line output from MCU which causes a perpetual SPI transfer from the Apalis (i.e. continuous ‘dummy’ writes from the Master) as long as the ‘data ready’ line is asserted.
  4. MCU as QSPI Master and Linux as QSPI Slave. Unsure of maximum bitrate. Is this possible at the hardware level? I believe it should be possible within Linux, but I’m not sure about the hardware SPI controller on the Apalis.

Any comments on the above would be greatly appreciated. Note that I’ve used an ethernet-based process in the past, but found the overhead of the ethernet stack on the MCU to be too large. For similar reasons I’m not looking to use USB, and the MCU doesn’t have a PCI-E interface. As such, the highest throughput, lowest overhead interface should be SPI/QSPI.

A bit of an update on this. I’ve confirmed with NXP that the iMX8 controller doesn’t support QSPI Slave mode, so option 4 can be ruled out.

Hi Matthias, my apologies for the delay, I somehow forgot to follow up on this question! It is an external MCU, not the internal M4 cores.

Regarding USB overhead. Something like FT245 is easy to interface, which is 8 bit bus + few simple control signals. It is full speed device, but I guess FTDI chip has similar ones for USB high speed.

SPI is risky until you try it and confirm that it is OK for your needs. Something well known like eCSPI, with its >10 years history still has problems with Linux driver. Hope LPSPI on iMX8 is better, but I wouldn’t rely on it until tested to achieve speeds you talk about. I believe you need to wire some test setup and benchmark it.


Hi Jars,
by MCU are you referring to an external MCU or one of the internal ARM M4 cores?

Best Regards,

Matthias Gohlke