gpio timing pins for kernel and userland scoping - feasible?

[mhaberler]

it'd be great to be able to optionally use a few GPIO out pins so they can be used for scoping events in-kernel as well as from arbitrary userland code, a bit like in this example

I do see the gpio driver present on the Terasic, so going from there it amounts to figuring the pin numbers to replicate the above code

machinekit@mksocfpga:~/machinekit/configs/hm2-soc-stepper$ find /sys/class/gpio/
/sys/class/gpio/
/sys/class/gpio/unexport
/sys/class/gpio/export
/sys/class/gpio/gpiochip427
/sys/class/gpio/gpiochip454
/sys/class/gpio/gpiochip483

the thing I'm unclear - how do I avoid the FPGA code trampling on those GPIO pins? I assume once the FPGA is loaded it 'takes over' the GPIO pins?

is it sufficient to build firmware replacing a few of these GPIO pins with 'emptypin' and I'm good?

do I need to take out a 'connector' here?

or, alternatively: maybe there is a way I can force the hm2 driver not to touch a few pins so they 'remain GPIO' ? (preferred ;)

[dkhughes]

SoCs like the Zynq and Altera's Cyclone SoC have two sets of pins. Some are accessible by the FPGA, some are dedicated GPIO, MIO, that the ARM processor can control directly. It is pretty common for those GPIO to be exposed in the filesystem. If you want to enable a specific GPIO, I think it would just be a modification to the device tree source files since you already have the necessary drivers in the image.

Edit: Just in case that was confusing....Yes, there are pins that only the processor can control as GPIO that are not available to the FPGA - hostmot2 can't touch them.

[mhaberler]

I see now the two 'gpio' headers on the nano are all fpga-connected so not candidates

maybe the LTC header pins can be coerced into gpio roles

that clears it up - thanks!

[mhaberler]

yes it can - the 2x7 LTC header could yield up to 5 'hps' (connected to processor) gpio pins provided i2c and spi on this header are not used - good enough!