swap SPI_CLK_M2 and SPI_CSN0_M2
Assuming you want to connect a second SPI slave-device you'll need a second dedicated CS signal (one of the available GPIO pins), and make sure only one of them is active (low) at any given time.

It's probably also a good idea to put a ~200Ohm resistor on your MISO line when you're experimenting with this, just in case Wink
Ok, that's what I was doing. I misinterpreted what you were saying about the device tree.

I thought you found some way of using the CSN0_M2 select for your own purposes.

I'm obviously not understanding something... If you're not using CSN0_M2 for your own chip select, and you're using an unrelated GPIO, then why bother disabling the on-board flash?

It if doesn't get selected, it tri-states MISO and other than the pull-ups on the Rock64, it is invisible.
That's because I'm having a second *master* device on the SPI bus, and it's not the flash chip I needed to disable (for which CSN0_M2 is fine) but the driving pins (CLK & MOSI) on the Rock. I verified this can be done on the command line (a C library to control the GPIOs is still on my todo- or wish-list though...).
That makes sense. Although, is there a period of time from Power On to reading the device tree that you'll have SPI bus contention?

Does any pre-device tree code access that flash?
Not 100% sure on that one tbh but the GPIOs *should* come up as inputs (with their drivers disabled), at least until the dtb tells them otherwise. Maybe someone can confirm this is indeed the behaviour?
FYI - enable SPI (with ayufan kernel with backported configfs) and RFE to rework SPI connectivity.
I left this community in Aug 2019 due to PINE64 refusal to produce/deliver ROCK64-1G version 3 after more than one year of changing statuses to "planning", "evaluating", "releasing", "availability", "estimated availability" and finally "no schedule" Angry. ROCK64 is dead platform without any advantage. Buy Raspberry PI 4 !

Forum Jump:

Users browsing this thread: 1 Guest(s)