> SPI support is labeled as broken in debian. And likely will remain so > until some one who understands it decides to work on it. Some of the > problem is in obtaining the headers for the gpio that is on the > individual card. > > Decent SPI support, as in error free writing at 41 megabaud, in 32 bit > packets, and reading back, error free, the results at 25 megabaud, from > a Mesa 7i90HD interface card over a 1" long cable, is currently done > ONLY from a user-space module that is now part of linuxcnc, and ONLY on > a raspberry Pi 3b. This code can probably be made to run on other > platforms, but so far I haven't even been successful at removing the "am > I running on a pi-3b checks". After that, then figure out how to get the > headers for the gpio part of the SoC thats on the boards you have, of > which there are apparently at least a dozen mutually incompatible > versions just from Broadcom. I'd certainly bow and give homage to the > person who can take rpspi.c and its limited header dependencies, rename > it to rkspi.c and make it run on the rock64 board at similar speeds. > Although its not that much faster than a pi, it comes without the very > small funnel that all non-gpio generated data must get (its an internal > usb2 hub) thru on a pi, and which throws away keyboard and mouse events > in wholesale amounts. The rock64, compared to the pi, feels to be at > least 5x faster than the pi will ever be because of this one difference > in internal architecture. > > A universal driver would be nice, but I suspect the best is going to be a > driver per platform. There is not a universal gpio, yet. Maybe another 5 > years for the winner to be shook out of the bushes far enough to become > a standard.
That's a drag, I bought a PocketBeagle a few months ago. SPI seems to be the only video. I'm still getting adapters together and such . It has 2 SPI
