+- PINE64 (https://forum.pine64.org)
+-- Forum: ROCK64 (https://forum.pine64.org/forumdisplay.php?fid=85)
+--- Forum: Linux on Rock64 (https://forum.pine64.org/forumdisplay.php?fid=88)
+--- Thread: swap SPI_CLK_M2 and SPI_CSN0_M2 (/showthread.php?tid=5473)
Pages:
1
2
swap SPI_CLK_M2 and SPI_CSN0_M2 - dontpostalot - 12-18-2017
Hi
I finally managed to get SPI going, all the signals seem to be there but I see my clock signal (SPI_CLK_M2, pin23 on PI2 header) where the chip select (SPI_CSN0_M2, pin24 on PI2 header) should be and vice versa.
How to swap these around?
Also, is it possible to stop/start driving these pins at runtime? How?
RE: swap SPI_CLK_M2 and SPI_CSN0_M2 - dontpostalot - 12-19-2017
These pins are indeed swapped, I just measured a short between pin 24 ont the PI2 and pin 6 (CLK) on the SPI-flash chip.
I have V2.0 of the Rock. Will this be corrected in later versions? Can I get a new device that does have these pins connected correctly?
RE: swap SPI_CLK_M2 and SPI_CSN0_M2 - xalius - 12-19-2017
Are the pins swapped vs the regular PI2 pinout? A while back I added SPI flash support together with ayufan and the SPI bus itself worked just fine, I guess I have to take a closer look at this again
Edit: My latest schematic seems to have Pins23&24 correct, and at least on the SPI flash side the pins seem to be ok too...
My schematic has:
SPI_CLK_M2 - Pin23 (on PI2 header) - GPIO3_A0
SPI_CSN0_M2 - Pin24 (on PI2 header) - GPIO3_B0
And that works out with the pins on my SPI Flash as far as I can see...
If there would have been a swap between my prototyp Rock64 and the production version, I would expect the production version not having working SPI flash...
RE: swap SPI_CLK_M2 and SPI_CSN0_M2 - dontpostalot - 12-19-2017
I triple checked this now, pin 24 on the PI2 header has the SPI CLK signal, at least on my Rock V2.0. The connection between the CPU and the flash chip seems to be fine though, it's only the PI2 header.
RE: swap SPI_CLK_M2 and SPI_CSN0_M2 - xalius - 12-19-2017
Ok I will check that on my side too once I get hold of my Rock64s again...
RE: swap SPI_CLK_M2 and SPI_CSN0_M2 - coldfish - 12-26-2017
We have checked and confirmed swap on SPI_CLK and SPI_CI0 on ROCK64 PI bus, however the connection to on board SPI Flash is correct.
RE: swap SPI_CLK_M2 and SPI_CSN0_M2 - GaryLa - 01-08-2018
(12-19-2017, 04:14 PM)xalius Wrote: Ok I will check that on my side too once I get hold of my Rock64s again...
Any verdict? Will you just keep these swapped in future revsions?
RE: swap SPI_CLK_M2 and SPI_CSN0_M2 - GaryLa - 01-09-2018
(12-18-2017, 10:25 AM)dontpostalot Wrote: I finally managed to get SPI going
What effort did it take?
RE: swap SPI_CLK_M2 and SPI_CSN0_M2 - dontpostalot - 01-10-2018
I received a message from support that they will fix it in future revisions, starting from V2.1.
To get SPI going you'll need to adapt the device tree and remove the MTD stuff, here are my notes:
// the SPI device is connected to an EPROM, it can be turned into a regular SPI device by adapting the device tree:
sudo apt-get install device-tree-compiler
dtc -I dtb -O dts /boot/efi/dtb > tmp.dts
// open the .dts file with a text editor and remove the existing eprom configuration (which is used for the 'mtd' storage devices), the relevant part should look like:
spi@ff190000 {
compatible = "rockchip,rk3328-spi", "rockchip,rk3066-spi";
reg = <0x0 0xff190000 0x0 0x1000>;
interrupts = <0x0 0x31 0x4>;
#address-cells = <0x1>;
#size-cells = <0x0>;
clocks = <0x2 0x20 0x2 0xd1>;
clock-names = "spiclk", "apb_pclk";
pinctrl-names = "default";
pinctrl-0 = <0x3b 0x3c 0x3d 0x3e>;
status = "okay";
spidev@0 {
compatible = "spidev";
reg = <0x0>;
spi-max-frequency = <0x2faf080>;
};
};
// save it, recompile and copy it back to /boot:
dtc -I dts -O dtb tmp.dts > tmp.dtb
sudo cp tmp.dtb /boot/efi/dtb
// after reboot the spi device should be present at /dev/spidev32766.0
RE: swap SPI_CLK_M2 and SPI_CSN0_M2 - GaryLa - 01-10-2018
Thanks for the notes!
Does your device get hit with any selects before the tree is loaded/configured?
Since IC (U1 Flash) is still connected to the SPI bus, and when you pull CSN0_M2 low -- how is it that 0's coming from U1 don't destroy 1's that you're driving from your device?