We’ve developed a Carrier board for the TX2, which is working fine. Our carrier board allows for attaching a 2nd board, called a COM board. These COM boards can vary in setups, thus also requiring different GPIO configurations (for example using CAN as actual CAN or just as GPIO’s).
How can we update a TX2 to change the pinmux used without connecting the TX2 to a host system? We’re already using the dd method of updating the device tree, but it is unknown on which partition the pinmux is stored, thus unknown which partition to update with dd to change the pinmux configuration.
Thanks in advance for any information/help,
PS: We’re currently running L4T 32.2.0
could you please share more details about updating pinmux without flashing for platform configuration.
you might check the flash messages, there’s step to update pinmux configuration for MB1.
please also refer to Jetson TX2 Boot Flow for the details of MB1,
We are able to generate the required files from the excel, then convert them with the python script, place them at the correct locations and modify a .conf file so the ./flash.sh script can use them.
However, you can only use the ./flash.sh script on a host system connected to the TX2. We want to be able to update a TX2 in the field without connecting it to a host system. We can already update the device tree by generating an encrypted DTB file with ./flash.sh --no-flash, and then use dd on the target TX2 to update the correct partition.
We also want to be able to do this for updating the pinmux settings. My question thus is which partion (kernel, kernel-dtb etc.) contains this information (this information being the pinmux settings) when generating an encrypted file with --no-flash. You are referring to MB1, I can’t find that as any partition name, might it be contained in any other partition, perhaps bootloader-dtb?
Edit: for example, trying to generate MB1_BCT gives an error:
sudo ./flash.sh --no-flash -r -k MB1_BCT tx2-carrier_revbc mmcblk0p1
[ 0.0036 ] Generating signature
[ 0.0045 ] tegrasign_v2 --key None --getmode mode.txt
[ 0.0053 ] Assuming zero filled SBK key
[ 0.0056 ]
Traceback (most recent call last):
File “./tegraflash.py”, line 1280, in
File “./tegraflash.py”, line 1149, in tegraflash_run_commands
File “/usr/lib/python2.7/cmd.py”, line 221, in onecmd
File “./tegraflash.py”, line 665, in do_sign
File “/home/falco/TX2-Projects/Linux_for_Tegra_3220/Linux_for_Tegra/bootloader/tegraflash_internal.py”, line 739, in tegraflash_sign_binary
if not _is_header_present(file_path):
File “/home/falco/TX2-Projects/Linux_for_Tegra_3220/Linux_for_Tegra/bootloader/tegraflash_internal.py”, line 70, in _is_header_present
file_size = os.path.getsize(file_path)
File “/usr/lib/python2.7/genericpath.py”, line 57, in getsize
OSError: [Errno 2] No such file or directory: ‘/home/falco/TX2-Projects/Linux_for_Tegra_3220/Linux_for_Tegra/bootloader/signed/mb1_cold_boot_bct_MB1_sigheader.bct.encrypt’
Failed to flash/read t186ref.
If you would like to have the setting to be applied in MB1, then flashing is the only option.
If you would like to have the new pinmux to be applied in Kernel, then please program from kernel before your use-case.
Thank you for your explanations. I took a look at your options and option 1 seems promising. I noticed that the it is possible that the tool generates a dtb which should be placed in /boot/. However, I thought that the Jetson TX2 didn’t use these files, but instead uses a dtb read from a different partition (kernel-dtb mmcblk0p28)? Or will that DTB only be used at boottime and be overwritten by the file read from /boot/? And if so, shouldn’t it then be possible to configure all pins modifying that dtb file, instead of only the 40 pins from GPIO header?
Edit: and normally the *bct-pad.cfg and *pinmux-gpio.cfg generated by the pythonscripts in L4T/kernel/pinmux/t186/ are used by the flashing script to configure the pinmux, how are they involved?
Yes, correct. During boot, it reads from kernel-dtb partition and same is defined under /boot/extlinux/extlinux.conf. When you use tool, it provides modified dtb and copies in /boot/ , same gets added in extlinux.conf. Currently the most usecase is for 40-pin header pins to configure sfio/gpio dynamically, that’s why tool has only 40pins.
Also, we have overrides mentioned in dtb which is read by tool. It then overrides the final pinmux value in cfg.