Jump to content

Armbian 4.83 SPI driver


Nick

Recommended Posts

Hi all, traditionally I have used Bananian on the Bannan Pi M1+, but I thought that I would give Armbian a go as there seems to be more activity here and there are tools for compiling an entire image from scratch :-)

So far I love Ambian, thank you for the work.

 

I have tried the vanilla Jessie image (both downloaded from here and compiled myself) on the Banana Pi M1+ and with the exception of the WiFi issuet which I solved from this forum, all ran well. However I can't seem to find an SPI driver. My apologies if there is another forum post about this, I did try searching but the search function removed SPI from the query due to it being less than 4 chars :-(

 

When I built my own image using the tools from this site, I did check the kernel configuration which was set to build in SPI support, but still no entry in /dev or a module to load.

 

Any help would be appreciated.

 

Thanks,

Nick

Link to comment
Share on other sites

SPI driver is present, but it needs to be enabled in Device Tree. This should be a good enough general instruction for changing DT configuration on device itself, but instead of modifying UART blocks you will need to edit one of SPI blocks.

Alternatively, if you already have build tools set up, it will be easier to build a kernel with required changes in dts file, in this case you will need to add a block like this to dts file for your device (example from sun7i-a20-olinuxino-micro.dts):

&spi2 {
	pinctrl-names = "default";
	pinctrl-0 = <&spi2_pins_a>,
		    <&spi2_cs0_pins_a>;
	status = "okay";
};

You will need to check legacy kernel configuration to select needed spi number and pinout variant, check "sun7i-a20.dtsi" for possible options.

 

Edit: what is the output of:

cat /proc/device-tree/model

I'm not sure what dtb/dts file is used for this device.

Link to comment
Share on other sites

Hi  zador.blood.stained,

Thanks for the info. I have started looking through the dts file, decompiling it as mentioned in the thread that you provided.

I have various sections with the pins defined, I also have this:

 

                spi@01c05000 {
                        compatible = "allwinner,sun4i-a10-spi";
                        reg = <0x1c05000 0x1000>;
                        interrupts = <0x0 0xa 0x4>;
                        clocks = <0x3 0x14 0x13>;
                        clock-names = "ahb", "mod";
                        dmas = <0x14 0x1 0x1b 0x14 0x1 0x1a>;
                        dma-names = "rx", "tx";
                        status = "okay";
                        #address-cells = <0x1>;
                        #size-cells = <0x0>;
                        pinctrl-names = "default";
                        pinctrl-0 = <0x15 0x16 0x17>;
                };
 
                spi@01c06000 {
                        compatible = "allwinner,sun4i-a10-spi";
                        reg = <0x1c06000 0x1000>;
                        interrupts = <0x0 0xb 0x4>;
                        clocks = <0x3 0x15 0x18>;
                        clock-names = "ahb", "mod";
                        dmas = <0x14 0x1 0x9 0x14 0x1 0x8>;
                        dma-names = "rx", "tx";
                        status = "disabled";
                        #address-cells = <0x1>;
                        #size-cells = <0x0>;
                };
I'm assuming that the device at 01c05000 is SPI0 and the device at ..6000 is SPI1, if that's the case then I'm happy with SPI0 enabled and SPI1 disabled for the moment. However looking at the compatible line, it would appear that it is trying to load the sun4i-a10 driver, I'm assuming this should be sun7i-a20?
 
Nick
 
Edit... 
I have just tried modifying the compatible line to sun7i-a20, recompiled and rebooted but still no spidev :-(
Link to comment
Share on other sites

Decompiled dtb file doesn't have labels from dts source, but you can still reference controller addresses in original source file in kernel tree.

You don't need to change "compatible" property because one driver is used for several SoC families.

Since you already have one SPI controller enabled by default, try reinstalling dtb package to revert your changes and then check dmesg log for any SPI related activity (dmesg | grep -i spi)

 

I'm assuming that the device at 01c05000 is SPI0 and the device at ..6000 is SPI1

Yes, you are right

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/arm/boot/dts/sun7i-a20.dtsi#n673

 

Edit: If I had to guess, SPI driver may require DMA driver, which wasn't enabled in this kernel version. It's enabled only in dev kernel config, so you may try compiling and installing kernel for dev branch. Or you can wait for new kernel release (@Igor said that may happen in ~1-2 weeks)

Link to comment
Share on other sites

Sorry for the late reply, I was working on site yesterday.

 

Sadly there was nothing at all mentioned in dmesg regarding SPI.

 

I tried compiling the dev branch but the kernel didn't compile for some reason. I didn't have time to look into why but I can do if it helps?

 

For the moment I think I'll just stick to the legacy kernel as I don't need the latest version for the moment but I do need the SPI driver.

 

If any testing etc. is needed however then just shout and I will be happy to try out new bug fixes, suggestions etc.

 

Thanks,

Nick

Link to comment
Share on other sites

For the moment I think I'll just stick to the legacy kernel as I don't need the latest version for the moment but I do need the SPI driver.

 

If any testing etc. is needed however then just shout and I will be happy to try out new bug fixes, suggestions etc.

 

Mainline kernel version updated 2 days ago, so there may be problems. If you are interested in mainline and have some time to test, there is a link to prebuilt 4.4 kernel here, it should have all necessary options enabled.

Link to comment
Share on other sites

Recommended way:

1. Make a backup. For example, full sdcard backup with dd of win32diskimager,

2. Download linux-image and linux-dtb packages to your device,

3. Uninstall existing linux-image (and linux-dtb if it is installed). Make sure to not reboot your device until you installed a new kernel,

4. Install new packages with dpkg.

Link to comment
Share on other sites

Ok, so I built an image of Jessie / next using Igor's compile script, booted that on the banana pi and using apt I removed linux image and linux dtb, then using dpkg I installed the new linux image and dtb from your dropbox link.

 

The pi booted fine, no issues at all however still no spidev in /dev and no mention of spi in dmesg sadly.

 

Edit.

On the plus side, the new image booted incredibly quickly even the first time when it was resizing the SD card etc. Logins seem to take a little longer though, with a gap of around a few seconds between entering the username and being asked for a password.

Link to comment
Share on other sites

Hi all, traditionally I have used Bananian on the Bannan Pi M1+, but I thought that I would give Armbian a go as there seems to be more activity here and there are tools for compiling an entire image from scratch :-)

So far I love Ambian, thank you for the work.

 

I have tried the vanilla Jessie image (both downloaded from here and compiled myself) on the Banana Pi M1+ and with the exception of the WiFi issuet which I solved from this forum, all ran well. However I can't seem to find an SPI driver. My apologies if there is another forum post about this, I did try searching but the search function removed SPI from the query due to it being less than 4 chars :-(

 

When I built my own image using the tools from this site, I did check the kernel configuration which was set to build in SPI support, but still no entry in /dev or a module to load.

 

Any help would be appreciated.

 

Thanks,

Nick

how you have solved wifi issue? please help me? better if U point me at the right post...

Link to comment
Share on other sites

Zador,

The kernel in your dropbox link appears to break wifi as well, I'm not sure if that helps you at all?

According to /var/log/syslog wpa_supplicant is trying to play with nl80211 I'm not sure if that makes any sense? Using the same SD card image if I remove your kernel and instead install linux-image-next-sunxi then the WiFi works again.

 

As for the dtb changes, I'm looking at that now. If I'm honest I'm struggling to get my head around the link that you have posted but I'm sure it will all make sense when I investigate it. I'll keep you posted.

Link to comment
Share on other sites

OK, I don't use onboard Wi-Fi so I have no idea what it requires and what may break it, I'll investigate it later.

 

The main part in that link as I understand it (I'll test later) is this - adding spidev subnode to spi controller node:

--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -192,6 +192,15 @@
        pinctrl-names = "default";
        pinctrl-0 = <&spi2_pins_a>;
        status = "okay";
+       spi2_0 {
+               #address-cells = <1>;
+               #size-cells = <0>;
+
+               compatible = "spidev";
+
+               reg = <0>;
+               spi-max-frequency = <50000000>;
+       };
 };
Link to comment
Share on other sites

Thanks for the explanation, I'll look at that now I'm guessing that I'll have to decompile the running dtb file and edit that as I still can't build the dev kernel from source at the moment.

 

As an aside, I've just quickly tested the wifi with the deb packages from your dropbox account. Your kernel image with your dtb package appears to break the wifi, however if you use your kernel image with the armbian dtb-next package the wifi works just fine. Sorry for the slight hijack, I just didn't want you to waste your time looking at the kernel image when it appears to be a dtb issue.

Link to comment
Share on other sites

next kernel branch has separate patch for banana pi m1+ that adds extra Device Tree file (sun7i-a20-bananapi-m1-plus.dts), dev branch doesn't have this patch. This should be sorted out once kernel 4.4 is declared "stable".

Edit: or this patch can be duplicated to dev branch, though it won't enable new 4.4 features like onboard audio and sunxi-ss.

Edit 2: Maybe some other patches from dev branch are required too.

Link to comment
Share on other sites

Ah does that explain the boot.cmd hack that is required to get the wifi working? I hadn't made the connection between there not being a dts/dtb file for the m1+ at all, but that would explain why the variable expansion in boot.cmd fails.

Link to comment
Share on other sites

Ok, i have tried creating my own patch for the kernel to add the extra info, the patch was placed in the userpatchs area. It didn't solve the problem, but then I'm not overly confident regarding patching or exactly how Igor's scripts compile the kernel etc. It's possible that my changes were either not being applied or just being overwritten.

 

Attempt number two was to modify the dtb file directly on the device. This approach I'm more confident with, however sadly still no spidev.

Link to comment
Share on other sites

OK, wiki is outdated, I managed to enable SPI (I'm testing on cubietruck) with following:

 

 

&spi0 {
	pinctrl-names = "default";
	pinctrl-0 = <&spi0_pins_a>,
		    <&spi0_cs0_pins_a>,
		    <&spi0_cs1_pins_a>;
	status = "okay";
    spi0_0 {
			#address-cells = <1>;
			#size-cells = <0>;

			compatible = "spidev";

			reg = <0>;
			spi-max-frequency = <50000000>;
	};
};

 

 

which loads spidev driver and creates device node

➜  ~  % ls /dev/spi*
/dev/spidev32766.0

But it also outputs this message:

[    3.388767] spidev spi32766.0: buggy DT: spidev listed directly in DT 

which leads to a conversation in mailing list which contains the "proper" way - patching spidev driver.

Link to comment
Share on other sites

Great to hear that you managed to get it to run. Which file did you patch with those lines?

 

I've created two patches but they don't seem to help.

 

--- ./sun7i-a20-bananapro.dts 2016-01-30 14:22:26.000000000 +0000
+++ sun7i-a20-bananapro-nick.dts 2016-01-30 15:22:50.134387022 +0000
@@ -243,6 +243,15 @@
     <&spi0_cs1_pins_a>;
  status = "okay";
 };
+spi0_0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ compatible = "spidev";
+
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ };
 
 &uart0 {
  pinctrl-names = "default";
 
 
and...
 
--- ./sun7i-a20.dtsi 2016-01-30 14:28:09.000000000 +0000
+++ sun7i-a20-nick.dtsi 2016-01-30 15:17:46.082850154 +0000
@@ -679,7 +679,7 @@
  dmas = <&dma SUN4I_DMA_DEDICATED 27>,
        <&dma SUN4I_DMA_DEDICATED 26>;
  dma-names = "rx", "tx";
- status = "disabled";
+ status = "okay";
  #address-cells = <1>;
  #size-cells = <0>;
  };
 
Link to comment
Share on other sites

Your patches are wrong, please check my previous post, spi0_0 block is inside of spi0 block. Also you don't need to patch dtsi file.

Edit:

You need to append spi0_0 block inside of spi0 block to sun7i-a20-bananapi-m1-plus.dts/dtb, assuming you are using this Device Tree configuration, you should be able to do it on the device tiself with dtc. I had to append both spi0 and spi0_0 blocks since default dts for cubietruck doesn't have any SPI interfaces enabled to start with.

Link to comment
Share on other sites

Oh wow, I missed the nesting! Well spotted. I've created a new patch, so we'll see how that goes.

 

Edit. As for the dtsi file, I agree that it doesn't appear to need patching as even without the patch the spi block is marked as enabled, I'm just not sure how / where it's being changed from disabled to okay?

Link to comment
Share on other sites

Sorry for the basic questions, after a close inspection of the build process I've realised that my patches aren't being applied anyway. I'm guessing it's a problem with the file paths at the top of the patch file, but despite testing a few different options I can't figure out what they should be?

 

--- a/arch/arm/boot//sun7i-a20-bananapro.dts 2016-01-30 14:22:26.000000000 +0000
+++ sun7i-a20-bananapro-nick.dts 2016-01-30 17:47:29.651279300 +0000
@@ -242,6 +242,15 @@
     <&spi0_cs0_pins_a>,
     <&spi0_cs1_pins_a>;
  status = "okay";
+ spi0_0 {
+       #address-cells = <1>;
+       #size-cells = <0>;
+
+ compatible = "spidev";
+
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ };
 };
 
 &uart0 {
Link to comment
Share on other sites

Edit. As for the dtsi file, I agree that it doesn't appear to need patching as even without the patch the spi block is marked as enabled, I'm just not sure how / where it's being changed from disabled to okay?

dtsi defines all available controllers, but leaves them disabled. Board-specific dts files complements (if needed) and enables needed sections (by overriding "status" property), i.e.

spi0: spi@01c05000 {
compatible = "allwinner,sun4i-a10-spi";
reg = <0x01c05000 0x1000>;
interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ahb_gates 20>, <&spi0_clk>;
clock-names = "ahb", "mod";
dmas = <&dma SUN4I_DMA_DEDICATED 27>,
      <&dma SUN4I_DMA_DEDICATED 26>;
dma-names = "rx", "tx";
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
};
&spi0 {
	pinctrl-names = "default";
	pinctrl-0 = <&spi0_pins_a>,
		    <&spi0_cs0_pins_a>,
		    <&spi0_cs1_pins_a>;
	status = "okay";
};
Link to comment
Share on other sites

Please try this file: https://dl.dropboxusercontent.com/u/5385968/sun7i-a20-bananapi-m1-plus.dtb

You need to put this in /boot/dtb/ on your device.

 

Edit: For the record, your patch should look like this

 

 

diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
index e62e4af..891a3b3 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
@@ -261,6 +261,15 @@
 		    <&spi0_cs0_pins_a>,
 		    <&spi0_cs1_pins_a>;
 	status = "okay";
+    spi0_0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			compatible = "spidev";
+
+			reg = <0>;
+			spi-max-frequency = <50000000>;
+	};
 };
 
 &uart0 {

 

 

and you should name patch file "0014-bananapi-m1-plus-add-spidev.patch" since it should be applied after "0010-bananapi_m1_plus_dts.patch"

Link to comment
Share on other sites

Hi Zador,

I've just tried your dtb file, sadly it doesn't seem to have worked.

 

It was a clean kernel source with none of my patches installed. If was however the dev kernel branch would that be a problem?

 

Thanks for the patch notes by the way, I am at least learning alot working through this.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines