Does OpenWrt use the SPI after booting

For Developers
1

Hello,

I have a custom hardware that only has 1 SPI which is connected to the boot flash.

I know when OpenWRT boots up, it reads the code and file system from the flash thru the SPI and puts it in memory.

My application needs to use the SPI, so im wondering after OpenWRT boots up and loads in the OS and whatever else it needs from the flash into RAM, does it keep using the SPI because i need to disable it and use it for my own purpose.

Thanks

2

OpenWrt does not do that.

Yes.

In practice everything that's needed for 'normal' operations will be cached in RAM (rare -ideally no- writes, outside of config changes, reads mostly satisfied from cache), but you can't pull the flash chip from underneath its feet (without serious development changes). The system is still running from its main system flash, the 'hot path' being cached does not imply running from RAM.

3

On most SoCs you can define additional SPI chip select lines in the dts by mapping them to a GPIO pin. This then creates independent ports spi0 spi1 etc. which access different chips. The default spi0 would be the flash chip and spi1 your hardware.

If you use an initramfs build it does not use the flash during runtime -- the bootloader loads the entire kernel+fs blob to RAM and launches it. Any files altered or created exist only in RAM, as there is no flash filesystem mounted. If you don't include an MTD driver at all, there will be issues retreiving MAC addresses and wifi calibrations stored in flash.

4

Thanks for the info, so if there are multiple chip selects, its all still using the same SPI, is there some code that knows when its ok to use the SPI and when its busy reading/writing to/from flash?

What code is that, Do you have a sample SPI user space code? I need to write to the SPI every few xxx seconds to read A/D converter is why im asking.

Also how do i tell it to use the initramfs so that I can use the SPI in peace after it boots?

Thanks

5

Typical XY problem.

So there are two SPI devices(slaves) connected to the same SPI controller(master).
The preferrable approach is to program a SPI device driver for your converter, and export the data via hwmon API. If configured properly, the Kernel's SPI subsystem will handle the muxing between the slaves.

Linux does have a limited SPI user space API. But you'll have to register it as a spidev.