Fix for broken HW SPI!!
-
I did some research and it seems there could be a fix for the HW SPI bug.
Seems there is a conflict at power up due to the fact that both CS0 and CS1 are both low at power up causing a problem by selecting two SPI devices to be on the bus at the same time.
Maybe this is the reason it works at all when there is only the flash connected.
Changing the device tree power up settings, by making both CS0 and CS1 high at power up using built in pull up resistors, solved the problem for some people, maybe it could work for omega as well?
Please see this link at the bottom on the page
Unfortunately i got no idea how to change device trees. Maybe one of you smart guys can try it?
-
@nsmith The device tree spec can be found here:
https://github.com/devicetree-org/devicetree-specification/releases
-
@crispyoz Awesome thanks, now we need someone who knows how to change the device tree to make CS0 and CS1 outputs, and both output a high during power up would probably do the trick if fixing this HW SPI bug thats been there for 7 years
-
@nsmith as much as I love your optimism, I'm not sure that a "silicon bug" can be resolved by optimism and a DTS. Omega2 uses MT7688 not MT6821, the SPI issue is well documented and minds greater than mine have yet to find a software solution other than that detailed by @luz
-
What these suggested device tree changes do is entirely replacing hardware SPI with software (bit banged) SPI.
Yes, this will make full duplex work, but it will also make flash rom (file system) access muuuch slower (because software SPI max speed is ~1Mbit/s, while hardware SPI is ~40Mbit/s if I correctly recall).
However, no need for that - you can use software SPI with the Omega2 without changing the device tree (which would require building your own OpenWrt image), thanks to the
spi-gpio-custommodule. You just can't use the same pins (7,8,9) as the hardware SPI does, so you'd need to reserve 3 other GPIOs for it (you can re-use GPIO6,SPI_CS1, however).The only reason to switch to software SPI entirely would be when you absolutely can't spare those 3 separate GPIOs and slowing down file system access by a factor 40 is not an issue.
Otherwise, just use
spi-gpio-customto create a separate SPI interface for your device(s) that need full duplex, it's as simple as:# insmod spi-gpio-custom bus<Y>=<devid>,<SCK>,<MOSI>,<MISO>,<mode>,<speedInHz>,<CS> insmod spi-gpio-custom bus0=2,11,5,4,0,100000,18- bus0=2 means that the software SPI device appears as
/dev/spidev2.0(first CS, second would be/dev/spidev2.1etc.) - GPIO11 is the SPI clock SCK
- GPIO5 is MOSI
- GPIO4 is MISO
- mode is 0, which means standard SPI
- speed is set to 100000 which would mean 100kHz, but it is irrelevant because software SPI always runs as fast as it can, ~1MHz on the MT7688, which is still slow in general SPI terms.
- GPIO18 finally will be CS for the device.
You can also have more than one device, by adding more (mode, speed, CS) triples, or you can run without CS by leaving it unspecified. The full syntax is:
# insmod spi-gpio-custom bus<Y>=<devid>,<SCK>,<MOSI>,<MISO>,<mode0>,<speedInHz0>[,<CS0>[,<mode1>,<speedInHz1>,<CS1>[,<mode2,...]]]
- bus0=2 means that the software SPI device appears as
-
@nsmith
I use GPIO11 for CS1, there is no boot issue.
I think it's because the Omega2's bootloader will set the GPIO11 as HIGH output during boot.Changing device tree cannot help in this case.
Because no matter how you set pull-up or whatever in device tree, the Omega2 need to access flash memory to load the kernel with the defined device tree.
