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