Nick Posted January 30, 2016 Author Posted January 30, 2016 You did, my apologies, I ended up getting side tracked by the other things that we were doing. root@bananapipro:~# cat /proc/device-tree/model LeMaker Banana Pro Which is interesting as I have boot.cmd pointing to sun7i-a20-bananapi-m1-plus.dtb root@bananapipro:~# cat /boot/boot.cmd # if you want to boot jessie with systemd: setenv bootargs init=/bin/systemd console=tty1 ... # remember to disable ramlog prior switching to systemd setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 cgroup-enable=memory swapaccount=1 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1" #-------------------------------------------------------------------------------------------------------------------------------- # Boot loader script to boot with different boot methods for old and new kernel #-------------------------------------------------------------------------------------------------------------------------------- if ext4load mmc 0 0x00000000 /boot/.next || fatload mmc 0 0x00000000 .next || ext4load mmc 0 0x00000000 .next then # sunxi mainline kernel #-------------------------------------------------------------------------------------------------------------------------------- #ext4load mmc 0 0x49000000 /boot/dtb/${fdtfile} || fatload mmc 0 0x49000000 /dtb/${fdtfile} || ext4load mmc 0 0x49000000 /dtb/${fdtfile} ext4load mmc 0 0x49000000 /boot/dtb/sun7i-a20-bananapi-m1-plus.dtb || fatload mmc 0 0x49000000 /dtb/sun7i-a20-bananapi-m1-plus.dtb ext4load mmc 0 0x46000000 /boot/zImage || fatload mmc 0 0x46000000 zImage || ext4load mmc 0 0x46000000 zImage env set fdt_high ffffffff bootz 0x46000000 - 0x49000000 #-------------------------------------------------------------------------------------------------------------------------------- else # sunxi android kernel #-------------------------------------------------------------------------------------------------------------------------------- ext4load mmc 0 0x43000000 /boot/script.bin || fatload mmc 0 0x43000000 script.bin || ext4load mmc 0 0x43000000 script.bin ext4load mmc 0 0x48000000 /boot/zImage || fatload mmc 0 0x48000000 zImage || ext4load mmc 0 0x48000000 zImage bootz 0x48000000 #-------------------------------------------------------------------------------------------------------------------------------- fi # Recompile with: # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr root@bananapipro:~#
zador.blood.stained Posted January 30, 2016 Posted January 30, 2016 Did you recompile your boot.cmd to boot.scr? Even if you didn't edit it, try recompiling it and testing "cat /proc/device-tree/model" after reboot again.
Nick Posted January 30, 2016 Author Posted January 30, 2016 Funnily enough, I just had the same thought, I was almost certain that I had recompiled it, but figured that I would try it anyway. Since recompiling the pi wont boot. U-Boot SPL 2016.01-armbian (Jan 30 2016 - 20:12:05) DRAM: 1024 MiB CPU: 912000000Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC U-Boot 2016.01-armbian (Jan 30 2016 - 20:12:05 +0000) Allwinner Technology CPU: Allwinner A20 (SUN7I) I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment Setting up a 720x576i composite-pal console (overscan 32x20) In: serial Out: vga Err: vga SCSI: SUNXI SCSI INIT SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: eth0: ethernet@01c50000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2341 bytes read in 343 ms (5.9 KiB/s) ## Executing script at 43100000 0 bytes read in 262 ms (0 Bytes/s) 28020 bytes read in 1159 ms (23.4 KiB/s) 4775680 bytes read in 540 ms (8.4 MiB/s) Kernel image @ 0x46000000 [ 0x000000 - 0x48df00 ] ## Flattened Device Tree blob at 49000000 Booting using the fdt blob at 0x49000000 Using Device Tree in place at 49000000, end 49009d73 Starting kernel ... Uncompressing Linux... done, booting the kernel.
zador.blood.stained Posted January 30, 2016 Posted January 30, 2016 It's possible dev kernel doesn't like dtb from older version, try using my dtb on fresh Armbian 4.5 image.
Nick Posted January 31, 2016 Author Posted January 31, 2016 Did you mean to try it on a fresh 4.5 or fresh 4.3.4 image? I've just tried 4.3.4 and that didn't work.
Nick Posted January 31, 2016 Author Posted January 31, 2016 I've been playing with a fresh 4.3.4 image that I've just compiled and had at least a small success... For the moment I've given up on patches etc. and just played with the files on the device. I have edited and recompiled boot.cmd to ensure that it is pointing to the m1-plus.dtb file (and confirmed with cat /proc/device-tree/model) Followed by adding your edits to the m1-plus.dtb file.I now finally have root@bananapipro:~# ls /dev/spi* /dev/spidev32766.0 Which although I haven't yet tested to see if pins are toggling is a great step forward. As a side note, where does the 32766 come from? I don't really care what the device is called, I just need to know that either it isn't going to change so that I can hard code it into my application, or find a reliable way of allowing my application to choose the correct device at runtime. Thank you ever so much for your help so far.
zador.blood.stained Posted January 31, 2016 Posted January 31, 2016 I'm glad that it finally worked. As a side note, where does the 32766 come from? I don't really care what the device is called, I just need to know that either it isn't going to change so that I can hard code it into my application, or find a reliable way of allowing my application to choose the correct device at runtime. udev, I guess? (based on comments in spidev.c and kernel spidev documentation)
ChrisArena52 Posted April 14, 2016 Posted April 14, 2016 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
Nick Posted April 14, 2016 Author Posted April 14, 2016 Most likely yes, the A20 SoC has a 64byte hardware buffer according to the datasheet, so this is a hardware limitation not a driver limitation. As far as I'm aware the SPIdev driver doesn't make any attempt at caching data if you decide to send more than that so you will have to do it your self. It's been a while since I looked at the driver, but there may (should?) be a way of determining the maximum amount of data that can be handled if the driver isn't going to actively buffer it for you. This is a good place to start for all things SPI https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-next/drivers/spi
ChrisArena52 Posted April 14, 2016 Posted April 14, 2016 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.
zador.blood.stained Posted April 14, 2016 Posted April 14, 2016 Is the limitation to 64 bytes still true in the vanilla version? Yes, still true, but we use one of proposed patches to bypass this limit (not really tested but should work).
ChrisArena52 Posted April 14, 2016 Posted April 14, 2016 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.
zador.blood.stained Posted April 14, 2016 Posted April 14, 2016 If you are building "next" kernel branch then this patch is already included, so you only need to activate needed SPI bus for your device with DT patch.
ChrisArena52 Posted April 14, 2016 Posted April 14, 2016 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?
zador.blood.stained Posted April 14, 2016 Posted April 14, 2016 Yes, "next" is stable vanilla, "dev" is latest available (including RC versions). I should be using Xenial? For build host? Doesn't matter, use either trusty or xenial, both should work.
ChrisArena52 Posted April 14, 2016 Posted April 14, 2016 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! 1
ChrisArena52 Posted April 15, 2016 Posted April 15, 2016 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!
zador.blood.stained Posted April 15, 2016 Posted April 15, 2016 Those numbers used to be labels in original DT source, so copying them from another device or even another kernel version will not work. To activate SPI and spidev on cubieboard2 you will probably need something like this patch diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts index 1fa832d..8a0731f 100644 --- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts +++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts @@ -130,6 +130,19 @@ status = "okay"; }; +&spi0 { + pinctrl-names = "default"; + pinctrl-0 = <&spi0_pins_a>, + <&spi0_cs0_pins_a>; + status = "okay"; + + spidev@0x00 { + compatible = "spidev"; + spi-max-frequency = <50000000>; + reg = <0>; + }; +}; + &ir0 { pinctrl-names = "default"; pinctrl-0 = <&ir0_rx_pins_a>; Save it as "userpatches/kernel/sunxi-next/cubieboard2-spi.patch" and run compilation process again.
ChrisArena52 Posted April 15, 2016 Posted April 15, 2016 I rebuilt with that patch as directed, installed, ... and transmitted 66 bytes via my SPI interface!! Thanks! Wow!! Now to try 1024 bytes! Solved!
ChrisArena52 Posted April 15, 2016 Posted April 15, 2016 I decided to look closely at the 66 bytes I got and found that there is still something going on after byte 63. The 32nd word's bytes are split up by 9.1 usec when clocking at 6Mhz. I got the 66 bytes OK in the end but with an unexpected pause. I don't know how to attach an image of the capture I have of the transfer. The "image" button opened a dialog without the option to browse to the file. It didn't upload the file. It just pasted the path I entered into this text. Dropbox gave me something that I can't use here. Doh!
ChrisArena52 Posted April 15, 2016 Posted April 15, 2016 In sending 512 bytes, there was no repeat of the pause in the data. @ 6Mhz, it took 870.9 usec to transfer 512 bytes. I'll stop now.
ChrisArena52 Posted April 28, 2016 Posted April 28, 2016 Is the SPI interface working equally well for the Cubieboard1 ? I got one (the one NewEgg has without flash), repeated the procedure but the SPI isn't coming up. How can you tell which dtb file is in use when the reference to it in the boot.cmd file is via a symbol fdtfile? Where is that value defined? Thanks, Chris
zador.blood.stained Posted April 28, 2016 Posted April 28, 2016 How can you tell which dtb file is in use when the reference to it in the boot.cmd file is via a symbol fdtfile? Where is that value defined? It is defined in u-boot config file at compile time (i.e. for cubieboard1): CONFIG_DEFAULT_DEVICE_TREE="sun4i-a10-cubieboard" Also you can check on device itself with "cat /proc/device-tree/model" and search for model name in kernel sources (arch/arm/boot/dts)
Toby123 Posted August 4, 2016 Posted August 4, 2016 Hallo, I'm glad to find some help here. Im working with Banana Pro (M1+) and tried the current vanilla image, but i cant see any spidev kernel module. I want to use Hardware SPI and SPI over Bitbang. Can you summarize again which linux image you used and which DTB- file? I have tried vanilla image and DTB from the Dropbox (sun7i-a20-bananapi-m1-plus.dtb), adapted boot.scr, but it won't boot after "starting kernel" message.
Thomas Posted August 17, 2016 Posted August 17, 2016 I'm glad that it finally worked. udev, I guess? (based on comments in spidev.c and kernel spidev documentation) dev = device_create(spidev_class, &spi->dev, spidev->devt, spidev, "spidev%d.%d", spi->master->bus_num, spi->chip_select); bus_num: 32766 chip_select: 0
Recommended Posts