I have followed the instructions to use the Excel sheet to modify the PinMux for the Jetson Nano. Since we eventually will move off of a DevBoard we are using the full PinMux file and not the 40 Pin one.
I copy the files into the Linux dev box under the hardware source tree and run:
make ARCH=arm64 tegra_defconfig
make ARCH=arm65 dtbs
then I copy the arch/arm64/boot/dts/tegra210-p3448-0000-p3449-0000-b00.dtb to the kernel/dtb/
then I run jetson-disk-image-creator,sh -b jetson-nano -r 300
This creates an image that I can flash onto the sd card and boot the Jetson Nano with.
However the GPIO pins do not behave as we expect them to and if I inspect the /proc/device-tree/ with dtc I see very different configurations then what we are expecting, but they seem to match the signals we see on the board.
The easy check is that we disable Pin8 in our PinMux but it is still being pulled up after inserting the SD card and booting.
I feel like I am missing a piece of the puzzle here or not understanding how to tell if our changes are working. (Our pin is not being pulled to 0 when it has an external source so that much is definitely still broken. The same circuit works on a RPi)
I did try another document that explained how to change the u-boot configuration and recompile it with the csv. I tried this and still no change, but I was reading that u-boot changes don’t need to be made in 32.5, is this true?
you may Flashing a Specific Partition instead of flashing the whole device by using the command line, ‑k switch.
it’s $ sudo ./flash.sh -k DTB ... to update device tree blob for the Nano platforms.
Make sure the /boot/extlinux/extlinux.conf file in your image doesn’t have an FDT entry or that you copy your customized tegra210-p3448-0000-p3449-0000-b00.dtb to /boot/ in the image and set the FDT entry to point to it.
The custom dtb file is deffinitly in /boot/ and I can uncompile it and confirm it is the one I generated with the PinMux spreadsheet. I don’t see an FDT entry in extlinux.conf either. I will try and add it. I didn’t see this step anywhere in the user guides for PinMux. Is this something that I should just know? Linux Kernel building is a relatively new area for me personally.
This could also be the issue. R32.5 changes the default location for the bootloader files from the SDcard to the internal 4MB QSPI-NOR flash. If you’re flashing to an SDcard connected to the host, you won’t be loading your DTB. Use parted ( or another partitioning tool ) to look at the layout of the SDcard and post the result here.
Given the above, adding the FDT entry will probably fix the issue for you. Just having it in /boot doesn’t do anything by itself.
I was able to get the flash.sh script to flash my Jetson Nano. I had to switch to a different USB chord before it would detect my devboard.
Anyway, I performed the flash and the cat of /proc/device-tree/nvidia,dtsfilename still shows the one from git-master_linux and not the one that I generated. The dtbbuildtime also still shows February when my dtb was built today. I used a multimeter and I am still seeing 3.3V on pin 8 which we disabled.
I then edited the extlinux.conf file to include:
I rebooted the Jetson and when it comes back up the extlinux file is still changed but nothing else has. The /proc/device-tree/ values are the same and I still see 3.3V on pin8
Then just before u-boot starts the kernel, you should see…
## Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
ERROR: reserving fdt memory region failed (addr=0 size=0)
ERROR: reserving fdt memory region failed (addr=0 size=0)
Using Device Tree in place at 0000000083000000, end 000000008303e659
copying carveout for /host1x@50000000/dc@54200000...
copying carveout for /host1x@50000000/dc@54240000...
If you see Flattened Device Tree blob at 83000000 like above, then the kernel is using the FDT that was supplied in the extlinux.conf file. If you see address 83100000, then it’s using the one c-boot loaded from the QSPI-NOR flash.
OK so the kernel_tegra210-p3448-0000-p3449-0000-b00.dtb is wrong but tegra210-p3448-0000-p3449-0000-b00.dtb is correct?
There’s an easy one time fix on the nano…
$ sudo dd if=/dev/mtd2 of=/dev/mtd1 bs=64K
That will simply copy the good dtb over the old one.
To fix on the host, I’d start by deleting bootloader/kernel_tegra210-p3448-0000-p3449-0000-b00.dtb.sb, bootloader/kernel_tegra210-p3448-0000-p3449-0000-b00.dtb, and bootloader/tegra210-p3448-0000-p3449-0000-b00.dtb. Then copy your good dtb to kernel/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb.
It should rebuild the bootloader kernel_tegra210-p3448-0000-p3449-0000-b00.dtb and tegra210-p3448-0000-p3449-0000-b00.dtb files then just error out. If you’ve verified that the files are the same, you can flash to the device if you need.
I am getting closer for sure. If I remove the 3 files from the the L4T/bootloader directory and then run the --no-flash command as you showed. One thing I noticed is that I used jetson-nano-qspi-sd instead of jetson-nano-devkit this whole time, I assumed that this should be the same thing for the B00 boards.
Anyway, once I did that I had only 2 .dts file is L4T/bootloader. I used dtc on both and made sure that they were the one I generated. I also ran the same hexdump as before and both had the correct date and path I expect. So great I thought everything was working.
Then I go and reflash the device (just the DTS). The flash is successful and I booted it up. I am still getting the same results as before from dtsfilename and dtbbuildtime.
I rerun the hexdump on mtd1 and mtd2, the results of these are the same as before the flash, with the old date and path showing up in mtd1. I ran the dd command and then did the hexdumps again, this time though the data in mtd1 looked corrupted or jumbled. I tried to reboot and it never booted. I am trying a full reflash now to get back in there and see.