SPI stopped working on custom build
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
spidevas well as when using the
On my own firmware build however (based on https://github.com/OnionIoT/source head), the
spidevstops 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
VCCdoe 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?
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?)
@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.
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
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-mt7621module in June, so the mainline might just be the only thing we need.