(07-17-2016, 12:05 PM)longsleep Wrote: @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?

(07-17-2016, 01:04 PM)longsleep Wrote: 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.

(07-17-2016, 10:28 AM)martinayotte Wrote: 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

---

---

Quote:martinayotte
   Unfortunately, both SPI0 and SPI1 are currently disabled, see at line 1838 :
   https://github.com/longsleep/build-pine64-image/blob/master/blobs/pine64.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>;

(07-18-2016, 07:36 AM)martinayotte Wrote: 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.

(07-17-2016, 02:34 PM)martinayotte Wrote: 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 ...

(07-18-2016, 07:36 AM)martinayotte Wrote: 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.