Yes, that does help and it is what I expected, thank you for the well
The issue I am trying to solve is to prove deterministically the state
of the pins throughout the boot up until my application runs and I have
control over how they are managed.
Why not just recompile the kernel and change the board-file to have
platform data for the SPI bus you want to use?
A bit of insight into my project is that I have an FPGA connected over
SPI and some GPIO, when I come to running my program which communicates
to the FPGA through spidev in userspace and mmapping GPIO, the FPGA SPI
interface has been trashed due to the pin outputs from the beaglebone on
boot. To solve the issue I have to run my beaglebone program to get the
pins into the right state, stop the program, reset the FPGA, then run my
program again and everything is well.
Why not just write a kernel driver that includes a spi protocol driver
and some GPIO abilities? Then you don't need to use spidev or mmaped
GPIO. Plus, you can get real interrupts for your GPIO, if you care.
At the moment I have this flow diagram:
1) Ball Reset Release State (known from datasheet)
2) u-boot pin muxing state (doesn't effect the expansion header so don't
3) kernel boot (_unknown_.. this is where expansion header pin muxing
and subsystem intitialisation happens - possible change of states?)
Kernel also can disable portions of the chip that aren't used. If you
don't have platform data setup in the board-file (or dt), you're
possibly at risk that the SoC disables those peripherals. Doesn't
sound like what you're hitting, but something to be aware of.
4) application runs (in control of pin states)
So an example of what could be happening is that the SPI_SCLK line could
come out of the Ball Reset Release State Low, then upon muxing and
initialisation the SPI_SCLK line could go High, which the FPGA would
take as the start a clock tick, then when I run my program the FPGA is a
clock tick out and the interface is useless until we get back in sync.
Isn't this the whole point of a chip-select line?
The FPGA shouldn't care what goes on while it's chip-select isn't
asserted. Pull up your chip-select.
The issue is that I don't know if the SPI_SCLK line gets changed when
the SPI subsystem is invoked...
It may. But if you wrote a kernel driver, have it simply setup the I/O
how you want (possibly using platform data), then pull the reset on the
FPGA, wait for the FPGA to come ready, and then start talking. That's
how it's usually done (in my experience). Connect the FPGA reset to a
GPIO, then you can reset it at driver init or if your kernel driver
detects that things are going screwy.