swap SPI_CLK_M2 and SPI_CSN0_M2

[dontpostalot]

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

[GaryLa]

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.

[dontpostalot]

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...).

[GaryLa]

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?

[dontpostalot]

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?

[mcerveny]

FYI - enable SPI (with ayufan kernel with backported configfs) and RFE to rework SPI connectivity.