swap SPI_CLK_M2 and SPI_CSN0_M2
#1
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?
  Reply
#2
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?
  Reply
#3
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 Smile

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...
Come have a chat in the Pine IRC channel >>
  Reply
#4
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.
  Reply
#5
Ok I will check that on my side too once I get hold of my Rock64s again...
Come have a chat in the Pine IRC channel >>
  Reply
#6
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.
  Reply
#7
(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?
  Reply
#8
(12-18-2017, 10:25 AM)dontpostalot Wrote: I finally managed to get SPI going

What effort did it take?
  Reply
#9
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
  Reply
#10
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?
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)