I have my board functioning and I wrote a demo C program to turn on a GPIO output. It appears you need to reflash the image to get this working on this particular board. Verified boot can’t be bypassed, yet you can’t use overlays to configure GPIO outputs with verified boot enabled. So you either reflash with the GPIO all configured the way you want them (not useful for development) or you reflash without verified boot. Do I have this right?
*** Please note that this reply is generated by LLM automatically ***
Based on the provided context, it appears that you are correct in your understanding of the limitations of using GPIO outputs on the Jetson Orin Nano board with secure boot enabled.
Secure boot is a feature that ensures the authenticity and integrity of the boot process by verifying the digital signatures of the bootloaders and the operating system. On the Jetson Orin Nano board, secure boot is enabled by default, which means that the board will only boot with signed images.
When secure boot is enabled, the board uses a set of predefined configuration files, including the device tree, to configure the hardware. These configuration files are signed and verified during the boot process. However, this means that you cannot use overlays to configure GPIO outputs, as overlays are not signed and verified by the secure boot process.
To configure GPIO outputs on the Jetson Orin Nano board with secure boot enabled, you have two options:
- Reflash the image with the GPIO configured the way you want them: This involves creating a custom image with the desired GPIO configuration and flashing it to the board. However, as you mentioned, this is not useful for development, as it requires a full reflash of the image every time you want to make changes to the GPIO configuration.
- Reflash the image without secure boot: This involves disabling secure boot and reflashing the image without the secure boot restrictions. This allows you to use overlays to configure GPIO outputs, but it also means that the board is no longer secure, as it can boot with unsigned images.
It’s worth noting that the Jetson Orin Nano board has a feature called “Force Recovery Mode” that allows you to reflash the image without secure boot. However, this mode is intended for recovery purposes only and should not be used as a regular development workflow.
In comparison, other boards may have different secure boot implementations or may not have secure boot enabled by default. For example, some boards may use a different secure boot mechanism, such as UEFI secure boot, which may allow for more flexibility in configuring GPIO outputs.
In summary, your understanding of the limitations of using GPIO outputs on the Jetson Orin Nano board with secure boot enabled is correct. You have two options: reflash the image with the GPIO configured the way you want them, or reflash the image without secure boot. However, the latter option compromises the security of the board.
Here is a step-by-step guide to reflash the image without secure boot:
- Place the target board into Force Recovery Mode.
- Run the following commands:
$ cd ${ToT_BSP}
$ sudo ./build_l4t_bup.sh -u <pkc_key_file> -v <sbk_key_file> mmcblk0p1
Where:
* `<pkc_key_file>` is the RSA private key file for your board.
* `<sbk_key_file>` is the Secure Boot Key (SBK) key file for your board.
* `<device>` is the device name, e.g., `jetson-orin-nano-devkit`.
3. Flash the device with the following commands:
```bash
$ boardctl -t topo recovery
$ cd bootloader/
$ sudo bash ./flashcmd.txt
Note that reflashing the image without secure boot will compromise the security of the board. It is recommended to use this option only for development purposes and not for production use.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
Hi nagel2,
What’s the Jetpack version in use?
Not exactly. Jetson-IO / DT overlay is the normal way to adjust GPIO/pinmux during Orin Nano development, so it does not mean the off-the-shelf Orin Nano Super devkit lacks GPIO output capability. The difference is that with secure boot enabled, boot-time configuration changes cannot be applied as unsigned updates and must go through a trusted flash, capsule, or OTA update flow
Yes, it does mean that an off-the-shelf system lacks output capability. It is not possible to turn on a GPIO output with an off-the-shelf system as far as I know. You need to reflash the QSPI to disable verified boot OR you need to reflash with a custom image that has been modified and signed. This is with the latest version available for the board.
This issue could be mitigated for many users if the image that is being distributed pin-mapped some of the GPIO outputs to the 40 pin header.
Thanks for the clarification — that is a fair point.
While Orin Nano does support GPIO output, with the current off-the-shelf image and verified/secure boot flow, enabling it on those header pins may require reflashing or a signed update path.
Pre-configuring a few commonly used 40-pin pins as GPIO by default would improve the out-of-box developer experience.