TX2i r32.4.3 stop GPIO toggling during boot sequence

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.

hello Eadams,

there’s device registration and gpiochips allocations during system boot-up.
could you toggle GPIO for your usage after boot complete?

Yes I could toggle afterwards, but our customer has some circuitry attached to the gpios that is controlled by them toggling. So the toggle during boot causes undesirable behavior. I have also noticed that this toggle does not happen from a software reboot. Is there a way to avoid that during a cold boot? Just to be clear, I am not talking about the pins going high when power is applied, I mean that when I power cycle the board there is a point during the boot sequence where the gpio pins invert for about 200-500 ms, then go back to their original value.

please confirm which GPIO you are talking about so that we can check

It’s a custom carrier board using pins H13, G14, A22, and A23. The signal names are GPIO8_ALS_PROX_INT, GPIO9_MOTION_INT, GPIO_EXP1_INT, and GPIO_EXP0_INT. Pinmux is gpio_pq4_pi4 (bank I, offset 4), can_gpio2_paa2 (bank AA, offset 2), gpio_mdm7_py6 (bank Y offset 6), and gpio_mdm1_py0 (bank Y offset 0).

After further investigation, I have found that this issue only seems to affect the TX2i gpios. TX2 and TX2-4G do not toggle on the same board with the same gpios.

Is there any update on this? Thank you.

you can try disabling DRAM ECC. the delay you are seeing is mostly due to scrubbing of DRAM.


all the pins you have mention are interrupt pins to tegra from gpio expanders and sensors. bootloader does not toggles those pins .
Can you share the pinmux and gpio file you are using with which you are seeing the issue.


I’m not sure which file you’re refering to for the gpio file, but this is the pinmux file we are using.
tegra186-mb1-bct-pinmux-quill-p3489-1000-a00.txt (28.2 KB)

ok, have you tried disabling dram ecc?

the file you have attached has no change from the setting nvidia is doing for these pins.
But you have your custom board. What devices are connected to these pins and what is it used for? Interrupt purpose?

one possibility could be

in devkit, cboot tries to communicate with the gpio expanders whose interrupt lines are GPIO_EXP1_INT and GPIO_EXP0_INT. Since your board has a different device connected, it can be possible that due to some activity, interrupts are getting generated?

You can try commenting the below code in cboot code and rebuild cboot.
err = tegrabl_tca9539_init();