SPI Pins for the Omega2



  • @WereCatf I generated my own build (LEDE + Onion feed), incorporated berniwa's patch to spi-mt7621, and am pleased to report it's working for me so far (testing with both spi-test and pyOnionSpi). My SPI slave target is an Atmel ATmega1284P and I'm validating the behavior in the ATmega using a JTAG debugger.

    I also flashed an O2+ with your provided image, and verified it with spi-tool. Of course, both of our patches include this warning:

                 if (t->tx_buf && t->rx_buf) {
                        printk(KERN_ERR
                            "The MT7621-SPI does not support full"
                            " bidirectional SPI, only doing TX!");
                }
    

    which generates arguably gratuitous chatter and probably ought to be removed (I'm removing it from my version of the patch).

    I also validated larger than 16-byte transfers work correctly (I tested writes, since my slave device is currently very simple and doesn't talk back yet).

    Pending a bit more testing, this patch seems like it ought to back upstream - would you consider doing the PR?

    Thanks for the help!



  • @Dana-Myers114 Sounds promising! I was just planning to test it out myself today with a fancy little project and, if it works, I'll report back here and then possibly discuss the patch with upstream.



  • I really, really want a logic-analyzer for this stuff, god dammit.



  • @WereCatf said in SPI Pins for the Omega2:

    I really, really want a logic-analyzer for this stuff

    Basic cy7c68013a board and sigrok is a cheap, effective solution for moderate speeds



  • So, I just obtained a logic-analyzer a couple of days ago and I tried to get fbtft running on the Omega2, but it's a no-go so far. While the kernel-module itself technically works and I am seeing the expected data on the SPI-bus, the display doesn't work.

    I took a capture from two other SBCs and the only meaningful difference I can see is that the Omega2 starts the SPI-bus clock and data-transfer immediately as it pulls the CS-pin low, whereas the other two SBCs pull CS-pin low, then wait 12 microseconds before starting the clock and data-transfer -- I have no idea, if this is a standard-procedure or if it is even the cause, but that's the only thing I can see, that jumps out at me.



  • @WereCatf presumably you've already confirmed the clock phase and polarity requirements of the display and that the MT7688 SPI is correctly configured? Are the other SBCs running the same bits (other than the SPI driver)?



  • @Dana-Myers114 Since it's fbtft that sets the clock-phase and polarity, yes, they are the same. I also specifically told it to use 500KHz SPI-bus speed, which the logic analyzer confirms as being in use.



  • I've finaly received an answer from Onion about that topic :
    "The SPI issue we will be investigating as soon as we can, however due to the overwhelming success of our crowdfunding campaigns, it may not be very fast. We also recommend submitting an issue to our github repo - or even a pull request if you work out a fix!"
    The discussion is a bit to advanced for me here, but if I can help, don't hesitate to ask.
    Brice



  • @Brice-Parent I've got a patch that I apply in my own build; I suppose I could do a PR for it into the Onion repo, though I think it really should go upstream into LEDE/OpenWRT. Before doing a PR for that, I need to confirm that this issue is present in all MT7621-type SPI peripherals (not just in the MT7688 used in the Omega2) because it would patch all of them. Given that actual full-duplex operation is not possible with the patch, it is potentially a regression if there's a flavor of MT7621 SPI that actually does work (though I suspect that's not the case)



  • Anyone still have got the discussed Patch? Unfortunately the Page from where it is form isn't alive anymore.


Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.