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.
according to comment #11, it seems kernel still uses the default device tree blob instead of yours.
btw, you should follow Jetson Nano - UART - JetsonHacks to setup serial console to gather bootloader messages.
thanks
I don’t have access to extra hardware right now. Getting a 5V jack was hard enough where I am right now. So I won’t be able to get the bootloader messages for at least a couple weeks.
However, I want to make sure that my steps are correct to change the PinMux because so far it seems that the documentation isn’t complete if we have to be changing the extlinux.conf file.
If we have a brand new environment this is what I assumed has to happen:
Make changes to NV_Jetson_Nano_Module_Pinmux_Config_Template.xlsm
Generate the DT file with the button in excel
Copy tegra210-jetson_nano_module-gpio-default.dtsi to Linux_for_Tegra/sources/hardware/nvidia/platform/t210/porg/kernel-dts/porg-platforms/tegra210-porg-gpio-p3448-0000-b00.dtsi
Copy ‘tegra210-jetson_nano_module-pinmux.dtsi’ to Linux_for_Tegra/sources/hardware/nvidia/platform/t210/porg/kernel-dts/porg-platforms/tegra210-porg-pinmux-p3448-0000-b00.dtsi
In Linux_for_Tegra/sources/kernel/kernel-4.9/ run:
make ARCH=arm64 tegra_defconfig
make ARCH=arm65 dtbs
Copy Linux_for_Tegra/sources/kernel/kernel-4.9/arch/arm64/boot/dts/tegra210-p3448-0000-p3449-0000-b00.dtb to Linux_for_Tegra/kernel/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb
run sudo ./flash.sh jetson-nano-qspi-sd mmcblk0p1
Boot the Jetson Nano
The disabled pin #8 should read 0V
The value of /proc/device-tree/nvidia,dtbbuildtime should read the day I built the kernel
The value of /proc/device-tree/nvidia,dtsfilename should show my directory structure
Are these steps correct? This seems to be what is required from reading the documentation. If I am missing a step can you tell me so I can try it while I wait to get access to a serial cable?
In the L4T/bootloader directory, you should see these files…
kernel_tegra210-p3448-0000-p3449-0000-b00.dtb
kernel_tegra210-p3448-0000-p3449-0000-b00.dtb.sb
tegra210-p3448-0000-p3449-0000-b00.dtb
The .sb file should be the dtb file you compiled. Make sure it is.
The two .dtb files are the signed versions.
If you do hexdump -Cn1500 on the .sb file you should see something like…
00000000 00 00 00 00 44 54 42 00 50 ba 03 00 00 00 00 00 |....DTB.P.......|
00000010 b1 ba ef be ad de ed fe aa aa aa aa aa aa aa aa |................|
00000020 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |................|
*
00000110 aa aa aa aa aa aa aa aa ee ee ee ee ee ee ee ee |................|
00000120 ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee |................|
*
00000220 ee ee ee ee ee ee ee ee 00 00 00 00 00 00 00 00 |................|
00000230 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc |................|
00000240 50 ba 03 00 00 00 00 00 b1 ba ef be ad de ed fe |P...............|
00000250 b1 ba ef be ad de ed fe 00 00 00 00 00 00 00 00 |................|
00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400 d0 0d fe ed 00 03 b6 42 00 00 00 48 00 03 6f a4 |.......B...H..o.|
00000410 00 00 00 28 00 00 00 11 00 00 00 10 00 00 00 00 |...(............|
00000420 00 00 46 9e 00 03 6f 5c 00 00 00 00 80 00 00 00 |..F...o\........|
00000430 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 |................|
00000440 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 |................|
00000450 00 00 00 03 00 00 00 48 00 00 00 00 6e 76 69 64 |.......H....nvid|
00000460 69 61 2c 70 33 34 34 39 2d 30 30 30 30 2d 62 30 |ia,p3449-0000-b0|
00000470 30 2b 70 33 34 34 38 2d 30 30 30 30 2d 62 30 30 |0+p3448-0000-b00|
00000480 00 6e 76 69 64 69 61 2c 6a 65 74 73 6f 6e 2d 6e |.nvidia,jetson-n|
00000490 61 6e 6f 00 6e 76 69 64 69 61 2c 74 65 67 72 61 |ano.nvidia,tegra|
000004a0 32 31 30 00 00 00 00 03 00 00 00 04 00 00 00 0b |210.............|
000004b0 00 00 00 01 00 00 00 03 00 00 00 04 00 00 00 1c |................|
000004c0 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 2b |...............+|
000004d0 00 00 00 02 00 00 00 03 00 00 00 15 00 00 00 37 |...............7|
000004e0 4a 75 6e 20 31 38 20 32 30 32 31 00 30 38 3a 34 |Jun 18 2021.08:4|
000004f0 37 3a 35 38 00 00 00 00 00 00 00 03 00 00 00 05 |7:58............|
00000500 00 00 00 4b 33 34 34 38 00 00 00 00 00 00 00 03 |...K3448........|
00000510 00 00 00 05 00 00 00 5b 33 34 34 38 00 00 00 00 |.......[3448....|
00000520 00 00 00 03 00 00 00 05 00 00 00 6f 33 34 34 38 |...........o3448|
00000530 00 00 00 00 00 00 00 03 00 00 00 04 00 00 00 82 |................|
00000540 00 00 b4 42 00 00 00 03 00 00 00 21 00 00 00 9a |...B.......!....|
00000550 4e 56 49 44 49 41 20 4a 65 74 73 6f 6e 20 4e 61 |NVIDIA Jetson Na|
00000560 6e 6f 20 44 65 76 65 6c 6f 70 65 72 20 4b 69 74 |no Developer Kit|
00000570 00 00 00 00 00 00 00 03 00 00 00 7b 00 00 00 a0 |...........{....|
00000580 61 72 63 68 2f 61 72 6d 36 34 2f 62 6f 6f 74 2f |arch/arm64/boot/|
00000590 64 74 73 2f 2e 2e 2f 2e 2e 2f 2e 2e 2f 2e 2e 2f |dts/../../../../|
000005a0 2e 2e 2f 2e 2e 2f 68 61 72 64 77 61 72 65 2f 6e |../../hardware/n|
000005b0 76 69 64 69 61 2f 70 6c 61 74 66 6f 72 6d 2f 74 |vidia/platform/t|
000005c0 32 31 30 2f 70 6f 72 67 2f 6b 65 72 6e 65 6c 2d |210/porg/kernel-|
000005d0 64 74 73 2f 74 65 67 72 61 32 31 30 |dts/tegra210|
The .dtb has the correct date and path while the .sb has the “default” date and path.
I ran the commands on the Nano as well and I got the same results. mtd1 has the Feb 19th date and the “default” path. mtd2 has the new date and my path.
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.
jetson-nano-devkit and jetson-nano-qspi-sd are both just symlinks to the same config file… p3449-0000+p3448-0000-qspi-sd.conf. It shouldn’t make a difference which one you use.
Same here.
What does that mean? Exactly what command did you run? If you flash only a single partition using the -k option, you need to do it twice, once with -k DTB and once with -k RP1.
Hello, Sorry for the delay getting back to this, had some office space issues I had to get sorted before I could try more.
I beleive that something is working now because stuff is breaking. Now when I flash the DTB and RP1 sections the Jetson will not boot. It is stuck on the NVIDIA screen. If I copy back the original .dtb into kernel/dtb and reflash the jetson will boot.
I also tried with the default Excel sheet before making any changes and I see the same. Is there a way to debug this before I get access to bootloader messages (Don’t have a way to buy the hardware right now)?
There are 9 copies of the device tree that I have found. 7 are on the SD card and 2 are on a 4MB flash on the SOM. It was a pain to finally realize the ones that matter are the ones of the 4mb flash.
However, even though I am now confident that the correct DTB is loaded and the DTB is configured with the DTSI files as per the documentation, we still can’t actually use the pinmux we configured. I agree that the process is broken.
As for not booting, I only got stuck at the nvidia screen when I tried to use a DTB for the 4GB nano and carrier board to try and boot a 2GB nano and carrier board. I believe the SOC is trying to look for hardware that isn’t available per the device tree. Make sure you are compiling the correct device tree for your test setup.
The excel sheet says “B01 SODIMM” on it. Which is the board I ordered. I was able to boot it successfully with the original “40 Pin Header” excel sheet. Does this mean we can’t use the “B01 SODIMM” pinmux for our devboards?
Disregard my comment about compiling the correct device tree. It looks like you are using the correct file - I went back and reread your previous posts.
So you gave me something to look at. It seems that using the “B01 SODIMM” pinmux might have been part of the issue. If I copy over the exact same configuration (only the available PINS) to the “40 Pin Header” excel sheet and export that one I can boot. I see the results (to a point) that I expect.
So I am not sure why this is the case, but it does allow me to boot.
Thank you gtj as well because your guidance helped me figure out how to flash the device tree in the first place.
I am seeing another issue now but it is related to the way I expect the Pins to work. But I think the original post is answered for now.