Jump to content

Armbian 4.83 SPI driver

Nick

By Nick
in Allwinner sunxi

 Share

Recommended Posts

Nick

Nick

Posted
  • Author
Posted

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:~#
Link to comment
Share on other sites
Nick

Nick

Posted
  • Author
Posted

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.
Link to comment
Share on other sites
Nick

Nick

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

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)

Link to comment
Share on other sites
ChrisArena52

ChrisArena52

Posted
Posted

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

Link to comment
Share on other sites
Nick

Nick

Posted
  • Author
Posted

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

Link to comment
Share on other sites
ChrisArena52

ChrisArena52

Posted
Posted

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. 

Link to comment
Share on other sites
ChrisArena52

ChrisArena52

Posted
Posted

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. 

Link to comment
Share on other sites
ChrisArena52

ChrisArena52

Posted
Posted

So what are the steps to enable the SPI port in total?

  1. decompile sun7i-a20-cubieboard2.dtb using dtc, not fdtdump
  2. modify the dts file to enable the SPI port I want (status="okay";), and pinctrl entries
  3. recompile the dts file, setting aside the original, and putting the new one in its place in /boot/dtb/
  4. modify the boot.cmd (backing up old) to point to the sun7i-a20-cubieboard2.dtb under /boot/dtb/
  5. 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!

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

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.

Link to comment
Share on other sites
ChrisArena52

ChrisArena52

Posted
Posted

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!


Link to comment
Share on other sites
ChrisArena52

ChrisArena52

Posted
Posted

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

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

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)

Link to comment
Share on other sites
Toby123

Toby123

Posted
Posted

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.

Link to comment
Share on other sites
Thomas

Thomas

Posted
Posted

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

 

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept