I’m thinking about using jumpers in GPIO pins to enable/disable configurations just like the barrell jack jumper does. However I’m not sure if it is possible. Here are some scenarios I would like to achieve:
If there is a jumper in GPIO 19 and 20 (Pins 24 and 26), the board does not load lightdm or any graphical interface at all (headless).
If there is a jumper in GPIO 19 and 20, I can check it in my C++ code and change the behaviour of my software.
Are these scenarios possible at all? I don’t know where to start.
I don’t have the details for particular carrier boards or device trees, but one can easily set up the device tree to define a GPIO pin as GPIO (not as interrupt or something else). One could then, in C++ or a shell script, check the status of that GPIO pin. There is a file in “/sys” for each GPIO pin which reflects its state, e.g., high or low. One would probably use a resistor though to go to ground or the positive rail (e.g., the 3.3V rail), but the GPIO definition might also be able to set active high or active low (I’m not sure, I haven’t worked with GPIO in a long time).
You’d want to look at the documentation for your particular L4T release (see “head -n 1 /etc/nv_tegra_release”), along with the PINMUX spreadsheet as a way to create the device tree you are interested in. See:
Also, examine the files in “/sys/class/gpio”. The PINMUX spreadsheet, vi macros (you’d have to enable them), can generate a device tree. A device tree is considered firmware, and can be updated in a number of ways (sometimes via flash, but but usually it is easier to test by naming it in the FDT key/value pair of “/boot/extlinux/extlinux.conf”); this in turn can be from the PINMUX spreadsheet, or an edit of the existing device tree using the dtc utility. On a more temporary test basis though, examine the “export” and “unexport” files under “/sys/class/gpio”. Also, examine the output of “cat /sys/kernel/debug/gpio”.
I’m using the developer kit of 4gb jetson nano. The first one released.
My doubt actually is if I can check whether there is a jumper in specific gpio pins or not. I know how to send signal to a GPIO pin, but I don’t know what happens when I jumper it and how to check it. I’m not even sure if it is possible to do it without some low level coding.
Also, I’m comfortable to just start jumpering GPIO pins and risk to fry something hehe.
For what is worth, this is my gpio debug data:
gpiochip0: GPIOs 0-255, parent: platform/6000d000.gpio, tegra-gpio:
gpio-2 ( |pcie_wake ) in hi
gpio-6 ( |vdd-usb-hub-en ) out hi
gpio-17 ( |sysfs ) out hi
gpio-38 ( |sysfs ) out lo
gpio-149 ( |sysfs ) out lo
gpio-151 ( |cam_reset_gpio ) out lo
gpio-168 ( |sysfs ) out lo
gpio-187 ( |? ) out hi
gpio-189 ( |Power ) in hi IRQ
gpio-190 ( |Forcerecovery ) in hi IRQ
gpio-200 ( |sysfs ) out lo
gpio-201 ( |cd ) in lo IRQ
gpio-202 ( |pwm-fan-tach ) in hi IRQ
gpio-203 ( |vdd-3v3-sd ) out hi
gpio-225 ( |hdmi2.0_hpd ) in hi IRQ
gpio-228 ( |extcon:extcon@1 ) in lo IRQ
gpiochip1: GPIOs 504-511, parent: platform/max77620-gpio, max77620-gpio, can sleep:
gpio-505 ( |spmic-default-output) out hi
gpio-507 ( |vdd-3v3-sys ) out hi
gpio-510 ( |enable ) out hi
gpio-511 ( |avdd-io-edp-1v05 ) out lo
A GPIO pin, if configured as plain GPIO (not IRQ), and configured as “input”, will reflect whether that pin is grounded (from the outside) or at 3.3V (from an outside source; be careful though, some carrier board setups will use 1.8V).
Notice in the debug output you found that some pins have “IRQ” in the output; those are used for triggering drivers in kernel space (they generate an interrupt and a driver will service the interrupt if you have such a driver). Others are listed as “out”; those drive the GPIO pin and you never ground those and you never apply power to them (you could put a meter or oscilloscope on the pin and watch it change as you alter the register in “/sys”…output will mirror input for “out” pins).
You are interested in the pins with label “in”, but not ones with some function already assigned. If you alternate between grounding an “input” pin and applying 3.3V (1.8V on some carrier boards or configurations; usually a resistor is used to tie the pin to ground or 3.3V depending on what state you want), then the file in “/sys” will also change. Your program would monitor the content of the “/sys” file, and your program could say something like:
bool state;
...code to monitor the GPIO /sys file and set "state" to that...
if (state)
...something for jumper to high...
else
...something else for jumper to ground...
Incidentally, what you want to do is “export” a pin as input. Then it will show up in the debug to verify it is input. Once that is done there will be a gpio file named after that gpio number within “/sys”.