fred@orin1:~/linux-5.10$ git status
On branch jetson_35.6_branch
Your branch is up to date with 'origin/l4t/l4t-35.6.0-5.10'.
nothing to commit, working tree clean
fred@orin1:~/linux-5.10$ git pull
Already up to date.
fred@orin1:~/linux-5.10$ git branch -a
* jetson_35.6_branch
master
remotes/origin/HEAD -> origin/master
remotes/origin/l4t/l4t-35.5.0-5.10
remotes/origin/l4t/l4t-35.6.0-5.10
remotes/origin/l4t/l4t-r34.dp-5.10
remotes/origin/l4t/l4t-r35.1.ga-5.10
remotes/origin/l4t/l4t-r35.2.1-5.10
remotes/origin/l4t/l4t-r35.3.ga-5.10
remotes/origin/l4t/l4t-r35.4.ga-5.10
remotes/origin/master
remotes/origin/rel-34-5.10
I feel there are some misunderstanding here.
What is the exact file you want to sync here? The pinmux file is not part of kernel thing. It is a configuration file for MB1 bootloader to take as input. And if you want a customization one for this, you either update that dtsi file by yourself or you use the spreadsheet to generate. But dtsi file is not quite easy to understand directly if you are new to it. That is why we suggest to use the spreadsheet.
bootloader directory is in the BSP too so sdkmanager will download it to your host PC.
If you don’t want to use sdkmanager, you could also download it from L4T archive page.
Hi,
After you generate the 3 files out, you have to put it to Linux_for_Tegra/bootloader and replace the old files. After replacing the old file, run the flash command again to flash the board.
As for which are the “old files”, it depends on what board you are using here. That could be discussed later.
It sounds like previously you don’t know where is this “bootloader” directory. That is what I am talking about in this reply.
And what I was trying to say above is “the script” mentioned by is not something related to pinmux. (I guess you are talking about source_sync.sh). That thing is used for syncing kernel source only but not pinmux thing. Also not for syncing the BSP.
Hi,
It seems I realized what is going wrong on your side. This is just another misunderstanding that confused you.
The source sync script will download another directly also called “Linux_for_Tegra” but that thing is totally not same as what I am talking about. I am talking about the BSP directory which is used for flashing your board.
The BSP directly is also named “Linux_for_Tegra” but the size of it is about 7GB at least. Your source code one won’t be this size… it is just they have same name so miled you.
And just in case you need to know what I am talking about… the BSP package is like this…
/nvidia/JetPack_6.1_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra$ ls
apply_binaries.sh jetson-agx-orin-devkit-industrial-qspi.conf odmfuseread.sh p3737-0000-p3701-0008-qspi.conf
bootloader jetson-agx-orin-devkit-maxn.conf odmfuse.sh p3740-0002-p3701-0008.conf
build_l4t_bup.sh jetson_board_spec.cfg p3509-a02-p3767-0000.conf p3740-0002-p3701-0008-qspi.conf
flash.sh jetson-orin-nano-devkit.conf p3701.conf.common p3767.conf.common
generate_capsule jetson-orin-nano-devkit-nvme.conf p3737-0000-p3701-0000-as-p3701-0004.conf p3768-0000-p3767-0000-a0.conf
igx-orin-devkit.conf kernel p3737-0000-p3701-0000-as-p3767-0000.conf p3768-0000-p3767-0000-a0-maxn.conf
jetson_additional_board_spec.cfg l4t_generate_soc_bup.sh p3737-0000-p3701-0000-as-p3767-0001.conf p3768-0000-p3767-0000-a0-nvme.conf
jetson-agx-orin-devkit-as-jao-32gb.conf l4t_sign_image.sh p3737-0000-p3701-0000-as-p3767-0003.conf p3768-0000-p3767-0000-a0-qspi.conf
jetson-agx-orin-devkit-as-nano4gb.conf l4t_uefi_sign_image.sh p3737-0000-p3701-0000-as-p3767-0004.conf README_Autoflash.txt
jetson-agx-orin-devkit-as-nano8gb.conf nvautoflash.sh p3737-0000-p3701-0000.conf rootfs
jetson-agx-orin-devkit-as-nx-16gb.conf nvmassfusegen.sh p3737-0000-p3701-0000.conf.common source
jetson-agx-orin-devkit-as-nx-8gb.conf nvsdkmanager_flash.sh p3737-0000-p3701-0000-maxn.conf Tegra_Software_License_Agreement-Tegra-Linux.txt
jetson-agx-orin-devkit.conf nv_tegra p3737-0000-p3701-0000-qspi.conf tools
jetson-agx-orin-devkit-industrial.conf nv_tools p3737-0000-p3701-0008.conf
jetson-agx-orin-devkit-industrial-maxn.conf odmfuse.func p3737-0000-p3701-0008-maxn.conf
Where is the correct one to download?
Sdkamager will download it when you tried to flash the board. What I just shared out is from sdkmanager.
I have that, sdkmanager is not picking up the files and installing. How do I get sdkmanager to pick them up?
Every time that is flashed it wipes out the previous install, this cannot be the correct way to do this.
Every time ubuntu is reinstalled and I have to reconfigure it. This happened on the 6.1 and 5.x. I did not see any options for a partial flash.
I just deleted the post. Figured out what you are talking about here…
Sdkmanager is not running on your Jetson… so there is no wipe out problem.
You are using sdkmanager in th wrong way.
I mean these files I shared out is on your host PC. They won’t be “wiped out” because you flashed your Jetson.
Your data on Jetson will be wiped out. Bur data on your host PC won’t…
Yes correct, I might not have been clear, its the target that gets wiped.
Surely you have some better way to do this.
Does a config file exist that needs to be updated with the 3 file additions?
As the document mentioned, you don’t meed to update pad voltage one but only gpio and pinmux.
Correct, something is preventing those files from being detected and placed on the target in the correct location.
Could you clarify the whole steps you have done here so that I can help review?
Configure in the spreadsheet, copy files to locations that are called out in the instruction. Start at step 01 and just follow the sequence.
Do those files require a special name?
I think you might need to share each file names that got replaced
Yes… they have fixed name… not a random one.