SPI Interface questions
#1
Hi folks,

I'm somewhat confused by the SPI interfaces in the RK3328 and thus their application in the ROCK64.

I've dug through all the documentation. It appears that there are three SPI interfaces in the RK3328, per Pg. 483 of the technical reference manual.

Code:
INTERFACE    CLOCK    RXD    TXD    CSN0    CSN1
                    
SPI0 (m0)    clkm0 : GPIO2B0    rxdm0 : GPIO2B2    txdm0 : GPIO2B1    csn0m0 : GPIO2B3    csn1m0 : GPIO2B4
SPI1 (m1)    clkm1 : GPIO3C7    rxdm1 : GPIO3D0    txdm1 : GPIO3D1    csn0m1 : GPIO3D2    csn1m1 : GPIO3D3
SPI2 (m2)    clkm2 : GPIO3A0    rxdm2 : GPIO3A2    txdm2 : GPIO3A1    csn0m2 : GPIO3B0    N/A


In ROCK64_Schematic_v2.0_20171019.pdf and the ROCK64 Pi2 Bus diagram....

Pi2 Bus Pin 24 is marked as "SPI_CSN0_M2", Pin 26 is marked as "SPI_CSN1_M0"

This is the first thing that confused me. Why do we have only one CS belonging to two different SPI interfaces on the header ?

The SPI2 (m2) Interface is exposed on the header. It has only on CS, and can only have one device on the bus. 
It appears that bus m2 is the same one used for the ROCK64 on-board 128M flash chip (U1) per page 6 of the schematics. 

Question 1: If so, how does one use the SPI interface on the Pi-2 bus without also addressing the onboard 128M Flash ?

Question 2: What was the purpose of exposing SPI_CSN1_M0 to the header when the rest of SPI_M0 is inaccessible ?

As far as I can tell, interface M0 and M1 are not used. In fact, it may even be that these interfaces aren't available on the BGA - I can't find them on the Ball Map.

I am wondering if future versions of the ROCK64 will make any changes? If so, is there a forum or suitable place to send suggestions ?

Suggestion: If possible, populate the header with a usable SPI bus e.g. m0 or m1, and provide both cs lines, e.g.

Pin 19: SPI_TXD_Mx 
Pin 21: SPI_RXD_Mx
Pin 23: SPI_CLK_Mx
Pin 24: SPI_CSN0_Mx
Pin 26: SPI_CSN1_Mx

Cheers.
  Reply
#2
Indeed, the naming of SPI pin is abit strange.... but ok.

So, to your question (1):

For CS-pin you can use any gpio pins, which are not used yet. To do this, you have to modify DTSI file, in this case rk3328.dtsi to assign any GPIO to SPI.

Which kernel are you using? Rockchip original (https://github.com/rockchip-linux/kernel)? Or ayufan (https://github.com/ayufan-rock64/linux-kernel)? Or from Rock64 (https://github.com/rock64-linux/kernel)?
  Reply
#3
Thanks, I'll test this shortly...

I'm starting with Ayufan's kernel. I'm planning on pulling together a very minimal 64bit aarch branch.

My project was all about NTP, and getting a highly reliable, redundant and accurate stratum 1 server. 

Prototype plan and layout thus far:

10/100 ethernet from 11x2 I/O for eth1
Cypress HX2VL USB 2.0 Hub provides 4 downstream ethernet ports.
Port 1 connects to RTL8152 10/100 ethernet driver for eth2
TI PoE front end on RTL8152 supports PoE recovery at class 4 (25W)
multi-output PSU includes 5v 4A and 3.3v from PoE in, with LiPo charge and auto-swapover to battery.
Cypress Port 2 connects to U-blox GPS module
Cypress Port 3 connects to Trimble GPS module
Cypress Port 4 connects to FT4232 quad port MPSS driver
FT4232 Port A currently unused
Port B runs in UART mode and provides a control interface to a Quantum CSAC
Port C runs in UART mode and provides a serial interface to the U-blox timecode
Port D runs in UART mode and provides a linux console to the Rock64
Rock64 GPIOs being used for Kernel PPS input., rotary encoder input and possibly a lower-resolution display.
I had hoped to use these for RGB 565 interface to drive an LCD. I didn't read enough of the docs.

For those wondering, the PCB that holds all this is currently 230mm x 65mm, and one end is compliant to the rock. 

Cheers.
  Reply
#4
(01-02-2018, 05:40 PM)bencrosby Wrote: Question 1: If so, how does one use the SPI interface on the Pi-2 bus without also addressing the onboard 128M Flash ?

Question 2: What was the purpose of exposing SPI_CSN1_M0 to the header when the rest of SPI_M0 is inaccessible ?

I am asking the same questions: https://forum.pine64.org/showthread.php?tid=5526

SPI_CSN1_M0 appears to be unusable as anything. And the SPI port on the 40-pin header does not have an "automatic" SPI chip select. Another GPIO will have to be used for it. Now I'm wondering if the usual Linux SPI kernel module will even allow cycles on SPI Module2 with this board. There are no chip selects available here...

Perhaps they got lost on the idea of allowing users to access the on-board flash and forgot about random uses of SPI.

I'm also not sure why there are NO CONNECTS on 11, 29 and 31. They're designated as valid GPIO and these are GPIO on the Raspberry Pi series.
  Reply
#5
i've also wondered and it occurred to me that the board itself , or i guess the chip [cpu] and basic outlying circuits had a design purpose of android tv box and not a multipurpose learning board like the rpi. a lot of people assume that all boards are designed to be just like the rpi and they are not. further, in order to do due diligence on a proposed purchase one would need to verify that the board is fit for the use case prior to buying it. rather than buying it and then complaining that this or that is not exactly like the rpi. which, it could be the case that this board was never meant to be exactly like the rpi except it can sorta fit in rpi cases. i do know that an audio daughter board was designed for this board as well as being able to interface with other audio boards so perhaps that caused some pin re-assignments?
  Reply
#6
(01-08-2018, 09:35 AM)dkryder Wrote: i've also wondered and it occurred to me that the board itself , or i guess the chip [cpu] and basic outlying circuits had a design purpose of android tv box and not a multipurpose learning board like the rpi.

All of that is understandable and no one is suggesting otherwise.

Electrically, we are wondering why bother to bring out an SPI like this?

Also, why say the 40-pin layout is compatible with RPi if there is no intent for the board to be used in this arena.

It is compatible. That is, GND, +3, +5 are exactly the same. The GPIOs are in the same positions including SCL, SDA and the SPI pins.

The issue is the lack of a Chip Select associated with the SPI they brought out. It's as if they brought out the wrong select line. The naming suggests they were trying to bring out CS0 and CS1 of Module 2. But instead brought out CS0 of Module 2, and CS1 of module 0.
  Reply
#7
(01-08-2018, 06:45 PM)GaryLa Wrote:
(01-08-2018, 09:35 AM)dkryder Wrote: i've also wondered and it occurred to me that the board itself , or i guess the chip [cpu] and basic outlying circuits had a design purpose of android tv box and not a multipurpose learning board like the rpi.

All of that is understandable and no one is suggesting otherwise.

Electrically, we are wondering why bother to bring out an SPI like this?

Also, why say the 40-pin layout is compatible with RPi if there is no intent for the board to be used in this arena.

It is  compatible. That is, GND, +3, +5 are exactly the same. The GPIOs are in the same positions including SCL, SDA and the SPI pins.

The issue is the lack of a Chip Select associated with the SPI they brought out. It's as if they brought out the wrong select line. The naming suggests they were trying to bring out CS0 and CS1 of Module 2. But instead brought out CS0 of Module 2, and CS1 of module 0.

Gary, I think you’re almost right.

AFAICT, there is only a single chip select on SPI module 2. That’s a limit of the 3328 SoC used on the Rock64 board. 

I believe there is (understandably) a massive shared core IP between the RK33series SoCs. 

3328 with 316 contacts, 3368 with 453 contacts and the 3399 with 828. 

I think the 3328 TRM contains info that is not relevant to its physical package (such as the additional two SPI modules) which are probably connected and exposed on one of the other SoCs. 

I like the Rock for its USB3, dual Ethernet, 4GB RAM and quad core. You’re right that it’s not as useful compatibility wise as a Pi. But way more powerful. 

I gave up largely with the header. I’m using downstream peripherals off the USB port. 

Ta.
  Reply
#8
I'm just using a GPIO for a select line and I'm going to heavily modify the kernel module that handles SPI.

I have boards I've built for BeagleBone and Pi that depend on an SPI interface. They are realtime, so I can't depend on USB.

I chose Rock64 as the next platform because of the same reasons you did. I was just looking to clarify things, not complain. Every piece of hardware has erratas, anomalies and bugs. I brought up the Pi only because they named the header Pi-2 and it closely matches the Pi.

I learned on another thread that pins 23 and 24 are swapped on the current board. (As of January 9, 2018). Someone on the IRC channel told me they would be swapped back in the future.
  Reply
#9
I kind of gave up using SPI on Linux SoC because I always ran into trouble using multiple devices on the SPI bus (chipselect control, DMA transfer issues), sometimes only high clock rates available (without changing a lot of the parent clocks) and general issues with IRQ triggered transfers. For my hobby projects I use MCUs now to do SPI and sometimes also I2C and other real-time critical tasks, kind of like the sensor hub controller in most mobile devices and then send the aggregated data to/from the Linux SoC...
Come have a chat in the Pine IRC channel >>
  Reply
#10
I agree with you, it's a nuisance.

But as you know, sometimes you just don't have the pin count to do anything else.

I don't have any pressing data that goes via SPI. I gave up trying to use it as a formidable transport bus many years ago. I move all realtime code to the MCU. I download code to be programmed, set parameters, and obtain status info only.

Since I'm not sure at this point how the SPI_CSN1_M0 is used with the SPI_xxxx_M2 pins I think I'll just bit-bang this in a kernel module and chain to the hi-res timer as the clock.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Unterstanding RK3328 UART Interface Register Offsets krjdev 0 1,222 06-03-2020, 07:17 AM
Last Post: krjdev

Forum Jump:


Users browsing this thread: 1 Guest(s)