SPI stopped working on custom build

Rogier Lodewijks

I'm getting started on getting the SPI bus on my Omega working using Rust.

I ported a SPI library (rppal) from the RasPi to Omega2 (In case anybody else is struggling with this: ioctl's are defined/composed differently on MIPS(el) than on other architectures!).

After getting my ioctl's sorted, everything seems to work fine using the stock firmware, both using the hardware spidev as well as when using the spi-gpio-custom driver.

On my own firmware build however (based on https://github.com/OnionIoT/source head), the spidev stops working. The device node is present /dev/spidev32766.1, ioctls work and my scope registers digital signals going over the bus... All data read on the bus however is the same byte, either using my own tool or the bundled spi-tool (not all ones or zeroes but the same byte each time). Tying the MISO to GND or VCC doe not change the data read.

Iv'e compared modules of my firmware and the stock, with these results:

Modules in stock fw, but not in mine:

dma_shared_buffer, mt76x8, ralink_eeprom_api, snd_pcm_dmaengine, snd_soc_core, snd_soc_ralink_i2s, snd_soc_simple_card, snd_soc_wm8960, snd_usb_audio, snd_usbmidi_lib, uvcvideo, v4l2_common, videobuf2_core, videobuf2_memops, videobuf2_v4l2, videobuf2_vmalloc, videodev

and vice versa: modules in my build, but not in stock:

ip6_udp_tunnel, mt_wifi, spi_bitbang, spi_gpio, tun, udp_tunnel, wireguard

What am I missing here? Any ideas on what could be wrong?

Rogier Lodewijks

Correction:

It is not only my own custom build that fails the test. Just tested with the pre-built omega2p-v0.2.0-b196.bin and has same problem. (Kernel version 4.4.74)

The build I get using oupgrade --force (omega2p-v0.1.10-b160.bin, kernel 4.4.46) has a working SPI (but is otherwise too old/buggy).

Any pointers where to look for the bug ? (spidev driver of the newer kernel?)

Maximilian Gerhardt

@Rogier-Lodewijks I encountered this strange thing a while ago, and someone else, too. https://github.com/OnionIoT/spi-gpio-driver/issues/4#issuecomment-419640799. Never had the time to investigate it further. It just broke at some version and noone noticed or did a regression test.

Rogier Lodewijks

I seem to have found a solution for this issue, or at least a work around that works for me: YMMV

I've merged in the OpenWRT repo (git merge -X theirs openwrt/lede-17.01) into my OnionIoT/source repo. That built flawlessly ! :). So we're running kernel 4.4.153 now. That's nice on its own (always recommended to keep up with LTS kernel versions!).

Anyway, the SPI problem persisted. Then I removed the original Onion patch file for the spi-mt7621 module (rm ramips/patches-4.4/9999-spi-mt7621.patch) and rebuilt the image. Now we're using the unpatched mainline SPI driver. Guess what: this seems to work flawlessly! I'm a happy man now.

I only did some quick smoke tests, so it could be other SPI stuff breaks because of the missing patch. On the other hand, there have been some commits to the spi-mt7621 module in June, so the mainline might just be the only thing we need.