After further looking into this with people more skilled in this than I am, we have found further issues with the SPI implementation on the radxa zero. (We have actually come to question why this has not been a subject much earlier. Is nobody using SPI with the meson g12a?).
The two problems we have identified are:
The pins used for SPI on the radxa zero are electrically floating and must have a pull-down applied for the communication to make any sense in the first place. This can be seen nicely in this first screenshot on the left. Here, no pull-down has been applied to the MISO pin and the signal is thus interpreted as 1 for most of the time, unless a signal is applied on either the SCK or MOSI pins, in which case they influence the signal on the MISO pin:
We finally applied a 10kOhm resistor to the MISO pin to pull it down to 0V. Again, maybe it is possible to define this pull-down in the device tree overlay but we wouldn’t know how to.
The second issue is that the CS isn’t correctly implemented on the g12a. As Neil Armstrong, the developer of the SPI driver for meson (spi-meson-spicc.c) put it (in the last paragraph):
/*
* The Meson SPICC controller could support DMA based transfers, but is not
* implemented by the vendor code, and while having the registers documentation
* it has never worked on the GXL Hardware.
* The PIO mode is the only mode implemented, and due to badly designed HW :
* - all transfers are cutted in 16 words burst because the FIFO hangs on
* TX underflow, and there is no TX "Half-Empty" interrupt, so we go by
* FIFO max size chunk only
* - CS management is dumb, and goes UP between every burst, so is really a
* "Data Valid" signal than a Chip Select, GPIO link should be used instead
* to have a CS go down over the full transfer
*/
This can clearly be seen on this second screenshot:
Radxa on the left, Raspberry Pi 3B on the right.
One can clearly see that the CS only goes to 0 when a a signal is applied to SCK. The enc28j60 thus does not interpret the message as a 16 bit message but as two separate 8-bit messages. We can see (again, on the left) that the enc28j60 does, for that reason, not reply with its revision id (as it does on the right, 0x06)
In summary, I think we’ll have to say that for us, the SPI implementation of the Radxa is too broken to be useful. On top of that pinctrl seems to have been implemented in a way that is fundamentally different from other platforms and it’s not sufficiently transparent to us how to tweak it to make it work for us. We’ll probably try to revert to e.g. the Raspberry Pi platform which may be less available, but better supported.