Is SPI Working?

[longsleep]

@martinayotte - did you disable uart3 to get spi1 going (they both use PD0 pin and thus conflict). With the fixed memor region for gmac spi0 works just fine and i am going to enable it. To enable spi1 i would have to disable uart3 or change the pins - suggestions?

[xalius]

Would this be a usecase for devicetree overlays? What would be needed to support those?

[longsleep]

Yes, but a newer Kern el is required for device tree overlay support. I do not see this to come to the Pine64 with the BSP Kernel ever. You will need mainline for that.

[martinayotte]

@martinayotte - did you disable uart3 to get spi1 going (they both use PD0 pin and thus conflict). With the fixed memor region for gmac spi0 works just fine and i am going to enable it. To enable spi1 i would have to disable uart3 or change the pins - suggestions?

Yes, but not only UART3, UART4 also since SPI1 is using those 4 pins.

---

Yes, but a newer Kern el is required for device tree overlay support. I do not see this to come to the Pine64 with the BSP Kernel ever. You will need mainline for that.

Even Mainline doesn't have it yet ...

Patches from Pantelis Antoniou have been submitted several times, first time in 2013, and now after several versions, still not there.
I've personally struggled to get that into Armbian 4.6.2, comparing Raspberry, Beaglebone and CHIP implementations, and pure coincidence, I've finally succeeded yesterday.
Now, time to develop several overlay other the simple tests I did until now.

Maybe I will start some kind of backport into PineA64 later, depending how much code differ ...

[User 3332]

You don't need CONFIG_SPI_SUN4I/CONFIG_SPI_SUN6I, but you need CONFIG_SPI_SUNXI=y

EDIT : BTW, the CONFIG_SPI_SPIDEV can also be done as modules, ie. : CONFIG_SPI_SPIDEV=m

---

---

martinayotte
   Unfortunately, both SPI0 and SPI1 are currently disabled, see at line 1838 :
   https://github.com/longsleep/build-pine6....dts#L1838
   Few weeks ago, I've tried to enable them, but unfortunately, they have some thing wrong in their definitions, since as soon they are enabled, the kernel boots and their some crash in vfe and other stuff and end up with root login in serial debug and I could see that ethernet is not working, even doing "ifconfig" completely hangs.

(quoting myself )

Ok ! I've spent more time on the case, and I've finally figured out !!!

In the AllWinner specs, the EMAC is mapped at address 0x1c30000 and supposed to use 64K of memory, but in the DTS, the register mapping is mapping 256K, which overlap many other peripherals such as the GPU, the HighSpeed Timer, the DRAM Controller and the SPIs.
When I've enabled with "okay" the SPIs, they were grabbing their respective memory spaces, and then when Networking was turned on, I was getting this message in dmesg :

sunxi-gmac 1c30000.eth: can't request region for resource [mem 0x01c30000-0x01c6ffff]

This gave me the clue !!! why "eth" is trying to map such addresses so big where it is clearly overlaps the SPIs ?

Looking at DTS, and even in the AllWinner original one, we can see :

               eth@01c30000 {
                       compatible = "allwinner,sunxi-gmac";
                       reg = <0x0 0x1c30000 0x0 0x40000 0x0 0x1c00000 0x0 0x30>;

Changing that with the following solve the issue, I've now both networking and SPIs running :

               eth@01c30000 {
                       compatible = "allwinner,sunxi-gmac";
                       reg = <0x0 0x1c30000 0x0 0x10000 0x0 0x1c00000 0x0 0x30>;

Do you guys know if this will make it back into a kernel update, or do you have instructions on how to implement this? I need both Ethernet and SPI working for a project. Any help/advice would be greatly appreciated!

Eric

[martinayotte]

Yes, longsleep already merged my fix for the next builds.
But if you are in hurry, and since it is in only in the DTB, it is easy to fix it yourself using dtc compiler.

[User 3332]

Yes, longsleep already merged my fix for the next builds.
But if you are in hurry, and since it is in only in the DTB, it is easy to fix it yourself using dtc compiler.

Thanks for the quick reply. I will wait for the next build.

[martinayotte]

longsleepYes, but a newer Kern el is required for device tree overlay support. I do not see this to come to the Pine64 with the BSP Kernel ever. You will need mainline for that.

Even Mainline doesn't have it yet ...

Patches from Pantelis Antoniou have been submitted several times, first time in 2013, and now after several versions, still not there.
I've personally struggled to get that into Armbian 4.6.2, comparing Raspberry, Beaglebone and CHIP implementations, and pure coincidence, I've finally succeeded yesterday.
Now, time to develop several overlay other the simple tests I did until now.

Maybe I will start some kind of backport into PineA64 later, depending how much code differ ...

Unfortunately, such backport seem to be ugly !
Even I wish to get it done, it will probably take to much effort.
I'm throwing the towel for now ...

[alevecchio]

Yes, longsleep already merged my fix for the next builds.
But if you are in hurry, and since it is in only in the DTB, it is easy to fix it yourself using dtc compiler.

Hi Martin.
I was reading an article in Adafruit's website about compile a DTB and does not look so hard. Maybe i can learnd and do it myself. Can you say the files i need to change and compile?

Article about Beaglebone Black Device Tree Overlay: https://learn.adafruit.com/introduction-...e/overview

Thanks

[adamw]

Great work guys!
Just so I'm clear, will both SPI0 and SPI1 be working in the next kernel or only SPI0?