A customer of ours is having a problem with the GPIO pins on one of our custom carriers. They have some hardware attached that requires full control of the GPIO output voltage, and have noticed the pins toggling when they power on the board. I have replicated this on one of our own boards as well and while it’s hard to get a precise timing, the toggle appears to happen just before the start of the Cboot sequence. I determined this by viewing the serial console while connecting the GPIO pin to an oscilloscope and adding a pause at the start of cboot. The serial console gets to this point before the pause:
NOTICE: BL31: v1.3(release):41d46a9cf
NOTICE: BL31: Built : 21:14:44, Jun 25 2020
ipc-unittest-main: 1519: Welcome to IPC unittest!!!
ipc-unittest-main: 1531: waiting forever
ipc-unittest-srv: 329: Init unittest services!!!
hwkey-agent: 40: hwkey-agent is running!!
hwkey-agent: 182: key_mgnt_processing …
hwkey-agent: 157: Init hweky-agent services!!
platform_bootstrap_epilog: trusty bootstrap complete
and the toggle happens at about the same time. Then after pausing for 5 seconds:
[0001.232] I> Welcome to Cboot
[0001.235] I> Cboot Version: t186-02737b3e
[0001.239] I> CPU-BL Params @ 0x235800000
[0001.242] I> Dram Scrub in progress
[0001.886] I> DRAM Scrub Successful
Here’s the full console output:
normalboot.txt (71.0 KB)
I have tried changing both the device tree and tegra186-mb1-bct-pinmux-quill-p3489-1000-a00.cfg to configure the pins as pull-down and “drive 0” according to the device tree generated by the pinmux template excel file and cfg generated by pinmux-dts2cfg.py. The toggle still occurred (although changing the pinmux to “drive 0” did invert the voltage so the pin went from 0 to 1 for about half a second then back to 0, instead of the other way around).
Can anyone tell me why this toggle is happening? It’s rather difficult to debug considering it seems to happen before the serial console is configured for Cboot.