Hi!
We do use an Apalis iMX6 board and TorizonCore.
The SPI is shared with the external MCU placed on the carrier board.
Apalis and MCU shares the control of one of the devices on the carrier board. The goal is:
Before the full boot of Apalis: the control is given to MCU.
After the boot and running the containers: control is given to Apalis.
I do have ability to synchronize the handover of the SPI (dedicated pin from MCU to Apalis) to prevent the bus collision between MCU and Apalis.
However I do have some question: what is a I/O configuration for SPI during initialization?
a) Does the iMX6 drive the MISO and SCK pins just after device tree or driver load by kernel?
b) Those are tristate (or pull-up/down) until the application uses spidev driver?
In other words: could I use those pins by external MCU before application using it is executed on Apalis? If no - then how could I initialize the SPI after the OS boots?
Everything related to the pinctrl (e.g. muxing, drive strength, pull-ups/pull-downs, etc.) is applied as soon as the SPI Controller driver loads. This means the settings are applied before you access SPI from user space (e.g. via spidev). However, if you compile the driver (spi-imx.ko) as a module it would only be applied when you load the driver (with modprobe/insmod).
There is another problem. U-Boot will also configure some pins, so if U-Boot does the configuration you might still have a conflict. You can disable it entirely if you don’t need it in U-Boot but maybe rethink the HW design and use a proper multiplexer instead.
I assume that initial state is inputs (for almost all GPIOs).
Which part of initialization is done under U-boot and what is done by the driver? Is there a documentation regarding those activities?
You wrote:
U-Boot will also configure some pins
You mean those configured in device tree?
What is the state of output pins (i.e. MOSI/SCK/CS) after the load of the SPI driver but before the usage of the SPI device by the user application (so before any transfer):
a) push-pull to a state defined by device-tree,
b) tri-state (input),
c) pull-up/down (defined by device tree)?
I agree the best way would be the hardware update - although I try to find a workaround for existing design.
Unfortunately, there is no documentation about this. You could try to read the source code of u-boot and linux to understand how the pin you’re interested in is handled.
Not directly, you should check the board file (from u-boot) to understand how u-boot handles each HW interface.
You can see here that the SPI node is disabled and it is not mentioned anywhere else inside u-boot, which means it will stay disabled.
The state of any pin referenced by the device tree node, should be the state define by its pinctrl.
Nope - as getting into uboot programming is not jump-start for us, we need to plan it into our schedule when other urgent tasks will be finished. When we will investigate your proposition, I will let you know back here.
