ChrisArena52

I rebuilt with that patch as directed, installed, ... and transmitted 66 bytes via my SPI interface!! Thanks! Wow!! Now to try 1024 bytes! Solved!

So what are the steps to enable the SPI port in total? decompile sun7i-a20-cubieboard2.dtb using dtc, not fdtdump modify the dts file to enable the SPI port I want (status="okay";), and pinctrl entries recompile the dts file, setting aside the original, and putting the new one in its place in /boot/dtb/ modify the boot.cmd (backing up old) to point to the sun7i-a20-cubieboard2.dtb under /boot/dtb/ run the command at the end of the boot.cmd file Once I figured out that fdtdump isn't equal to dtc doing the decompiling, my new dtb worked, but no joy with the spi device. I get this repeatedly in dmesg here and there: [ ... ] sun4i-spi 1c05000.spi: could not find pctldev for node /clocks/clk@01c200a0, deferring probe My definition: spi@01c05000 { compatible = "allwinner,sun4i-a10-spi"; reg = <0x1c05000 0x1000>; interrupts = <0x0 0xa 0x4>; clocks = <0x3 0x14 0x15>; clock-names = "ahb", "mod"; dmas = <0x16 0x1 0x1b 0x16 0x1 0x1a>; dma-names = "rx", "tx"; status = "okay"; #address-cells = <0x1>; #size-cells = <0x0>; pinctrl-names = "default"; pinctrl-0 = <0x15 0x16 0x17>; }; Is there something missing from that? That spec differs in the clocks line and dma's line than the post from January, but its what came out of the decompile. I added the pinctrl-0 from the January post. What do those number refer to? The module spidev is loaded. My /proc/device-tree/model is: Cubietech Cubieboard2 uname -a : Linux cubieboard 4.4.6-sunxi #3 SMP Tue Apr 12 11:46:53 EDT 2016 armv7l armv7l armv7l GNU/Linux and lsb_release -a: Distributor ID: Ubuntu Description: Ubuntu 14.04.4 LTS Release: 14.04 Codename: trusty Thanks!

Xenial is one of the first options after starting compile.sh. My build host is trusty. I started again and selected trusty this time for the system to build. BTW, this build system is so nice!

OK, maybe that's the thing I'm really missing. The vanilla and the "next" version aren't the same thing? I should be using Xenial?

I have the built version of the vanilla version in a VM I ran to build it. Under userpatches, I should include that patch file you referenced, and a modified DT source file? Is there a patch file to update that via the patch mechanism? I'm completely new to this so I don't know my way around this stuff.

I thought that the 64 byte limit, which is actually 63 bytes as the 64th doesn't actually go over the wire, was due to the fact that the initial driver didn't engage the DMA mechanism to keep the fifo filled. A 64(63) byte transfer limit is hobbling that port. Thanks for the link.

Are the changes to enable the SPI driver summarized somewhere? Is the limitation to 64 bytes still true in the vanilla version? In the legacy version I can do SPI, but if I try to send what would be byte 64, that isn't transmitted and the device hangs up. I have to reboot to clear it. There are other issues with the legacy SPI driver it would be nice to fix. Thanks, Chris

Thanks for the links, but I have seen both of those. The only parameters that seem clear are max_speed_hz and full_duplex. In reading the spi.h file, is seems as though the fex subsection called spi_boardN should be call spi_slaveN, which helps to make sense of the parameters in the board section such as the chip_select. Same idea maybe for the spiN_para corresponding to spiN_master. But that doesn't explain the 1 to 1 correspondence always seen between the spiN_para and the spi_boardN entries. Its as though someone want me to think they're one to one. For spi0_para, there are two chip selects, so there could be two spi_boardN sections for that one spi interface if the spi_boardN section had a correspondence to a slave. An example in the Fex Guide illustrating that would go a long way! Does the bus number N correspond to the spiN_para? Are comments allowed in the fex file? They're really needed. To really understand what those parameters mean, do I have to read the spidev code? I'll look. Thanks, Chris Hallowell EMC

Hi, I just joined up so I'm an extreme newbie here. I'm running the legacy trusty version of Armbian just downloaded. The HDMI display and USB ports are working fine. The Cubieboard2 is showing up in the network. I need to get the SPI interface going to talk to a microcontroller -- an STM32F303. I've enabled the particular SPI port I need in the cubieboard2.fex file (derived from the stock cubieboard2.bin file) and created the cubieboard2.bin file in /boot/bin after backing up the original. After that change, I rebooted. I got the /dev/spidev0.0 to show up. What do the parameters in the spi_board section mean? Is that documented somewhere? Thanks, Chris Hallowell EMC