Hi, I am working with our HW team to bring up Xavier NX on a new carrier board. The new carrier board differs from the carrier board of NX DevKit in the following ways:
- CAMI2C bus goes to 4 lane I2C mux (PCA9546ARGYR) which interfaces with 4 cameras.
- NVMe connected to the I2C0 bus compared to the dev kit which uses the I2C2 bus.
- GPIO pins 1 through 14 are used differently than the dev kit.
Following the document “Jetson Xavier NX Adaptation and Bring-Up”, the pinmux table is modified and three .dsti files are generated:
I have two questions for adopting the pinmux changes:
- Since the pinmux changed, I need to update the MB1 CFG files with the tools in Linux_for_Tegra/kernel/pinmux/t19x/. How many CFG files I need to generate and which original CFG will be replaced ?
- Do I need to use these .dtsi files to update the device tree?
don’t include those generated *.dtsi into device tree sources, you’ll need to run this tool,
pinmux-dts2cfg.py to converts pinmux, gpio and pad dts file to cfg format; you’ll need to perform full flash to apply the cfg file update.
The README file has an example, that feeds both pinmux and gpio .dtsi into the python script and generates one CFG file. I want to know how many CFG file to generate with this python script? and where to put the generated CFG files?
Based on the README file, using the python script I can generate two CFG files:
pinmux.cfg and padvoltage.cfg. The pinmux.cfg needs tegra19x-jetson_xavier_nx_module-pinmux.dtsi and tegra19x-jetson_xavier_nx_module-gpio-default.dtsi as input.
Then copy pinmux.cfg and padvoltage.cfg to Linux_for_Tegra/bootloader/t186ref/BCT/ to replace these two files:
is this right?
you may refer to flash messages, it uses the pinmux configuration file as following,
you may check and replace the cfg file to flash the target.
@JerryChang I assume my Mar/10 post is right since you did not answer all the questions. We downloaded the NX pinmux table, which was released on 2020/04/22. Without any change we generated the untouched .dtsi files. Then converted to CFG files (pinmux.cfg and padvoltage.cfg). After flash to a NX DevKit, I got pinmux error in the console log (attached, Line 582). Consequently I got a fw failed to load, Line 599.
console-log-untouchedCFG (56.4 KB)
Since the pinmux template was release about two years ago, do you have an updated version or do you know the fix?
we’ve replaced below two cfg file by generate from default pinmux setting to flash Xavier-NX.
we’ve test this and confirmed we cannot reproduce the same failure.
Do you use the same pinmux table template, that released in 2020/04/22? If so, could you send me a copy of the file and I can use it to re-generate the untouched .dtsi files.
if possible, please send me your .dtsi files and the converted CFG files as well.
BTW, I can upload the untouched .dtsi files (generated with the default values from pimux table) and converted CFG files here for your reference. Thanks.
tegra19x-jetson_xavier_nx_module_untouched-gpio-default.dtsi (1.9 KB)
tegra19x-jetson_xavier_nx_module_untouched-padvoltage-default.dtsi (1.3 KB)
tegra19x-jetson_xavier_nx_module_untouched-pinmux.dtsi (54.4 KB)
untouched_padvoltage.cfg (568 Bytes)
untouched_pinmux.cfg (27.2 KB)
I would like to have double confirmation.
- we’re also using the pinmux through download center, you may check and download pinmux spreadsheets again to repeat the steps.
- is this customize board or developer kits? the default pinmux configuration settings applied to Xavier NX DevKits, please update the pinmux if you’re using customize boards.
- please also share all the commands, python command to convert the cfg and commands to flash the target for reference,
- The pinmux spreadsheets you pointed is exactly where we downloaded. I can repeat this one more time though.
- This is the official NX DevKit. We use the NX DevKit to compare the results with our customized board. Since we see the problem on our board, we want to make sure the NX DevKit can use this pinmux spreadsheet without any issue. Unfortunately the NX DevKit has the same problem.
- We followed all the steps in the user guide. The .dtsi file were generated with the tool with the spreadsheet. And the python script in kernel/pinmux/t19x/ was used to convert the dtsi to BCT cfg files. I followed the examples in the README file, without using the --mandatory-addr-info option. The cfg files were copied to the bootloader/t186ref/BCT. Looks like we replaced the right files from your last posting.
Please correct me if I missed anything.
Since you cannot reproduce the problem and if we followed the same procedure, I think it is a short cut to compare the files I uploaded. Or you can share your pinmux spreadsheet and generated files and I do a comparison.
Good News! I found that your pinmux.cfg is same with the default cfg file and different from mine. So I regenerated the dtsi files and re-converted the dtsi to cfg files. This time I got the same pinmux cfg file with yours. Not sure why the previous pinmux.cfg was massed up. Reflased the target and system works fine.
Thanks for your support and this topic can be closed.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.