[L4T 32.6.1 TX2 NX] Loading default dtb trough extlinux FDT causes kernel to hang

Hi, from this threads:

loading device trees trough extlinux FDT should be fixed on the TX2 NX in L4T 32.6.1.

Unfortunately I’m seeing the same behavior where kernel boot hangs when loading even the default device-tree for the TX2 NX:

Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
339 bytes read in 55 ms (5.9 KiB/s)
1:      primary boot/Image
Retrieving file: /boot/Image
34484232 bytes read in 941 ms (34.9 MiB/s)
append: console=ttyS0,115200 video=tegrafb earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x1772e0000 gpt rootfs.slot_suffix= usbcore.ol
d_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0
x10000@0x175840000 sdhci_tegra.en_boot_part_access=1  root=/dev/mmcblk0p1 ro rootwait gasket.dma_bit_mask=32 pcie_a
spm=off l4tver=32.6.1  sdhci_tegra.en_boot_part_access=1
Retrieving file: /boot/tegra186-p3636-0001-p3509-0000-a01.dtb
192576 bytes read in 59 ms (3.1 MiB/s)
## Flattened Device Tree blob at 82400000
   Booting using the fdt blob at 0x82400000
ERROR: reserving fdt memory region failed (addr=0 size=0)
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 0000000082400000, end 000000008243203f
copying carveout for /host1x@13e00000/display-hub@15200000/display@15200000...
copying carveout for /host1x@13e00000/display-hub@15200000/display@15210000...
copying carveout for /host1x@13e00000/display-hub@15200000/display@15220000...
DT property /chosen/nvidia,bluetooth-mac missing in source; can't copy
DT property /chosen/nvidia,wifi-mac missing in source; can't copy
DT property /reserved-memory/ramoops_carveout/alloc-ranges missing in source; can't copy
DT property /reserved-memory/ramoops_carveout/size missing in source; can't copy

Starting kernel ...

At this point the TX2 NX hangs and no kernel boot logs are printed.

I’m using the latest u-boot revision 46e4604c78d3804ccd4cf9624460a86ea5318a61 from nv-tegra.nvidia Code Review - 3rdparty/u-boot.git/commit branch tegra-l4t-r32.6.1,

and the default kernel Image + pre-compiled dtb from the L4T 32.6.1 BSP archive

DEFAULT primary
TIMEOUT 10
MENU TITLE Boot Options
LABEL primary
      MENU LABEL primary boot/Image
      LINUX /boot/Image
      FDT /boot/tegra186-p3636-0001-p3509-0000-a01.dtb

Can you please check and let me know if there’s a patch that I can apply to fix this? Thank you!

hello AlexCo,

could you please have a try to update the u-boot binary with the attachment manually,
thanks

Hi @JerryChang and thank you for your reply. I have tested the u-boot binary you shared and that one boots the kernel when passing the dtb:

U-Boot 2020.04-g1290f21 (Jun 17 2021 - 15:56:34 +0800)

SoC: tegra186
Model: NVIDIA P2771-0000-500
Board: NVIDIA P2771-0000
DRAM:  3.8 GiB
MMC:   sdhci@3400000: 1, sdhci@3460000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   
Warning: ethernet@2490000 using MAC address from ROM
eth0: ethernet@2490000
Hit any key to stop autoboot:  0 
Card did not respond to voltage select!
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
914 bytes read in 20 ms (43.9 KiB/s)
1:      primary kernel
Retrieving file: /boot/initrd
7238344 bytes read in 186 ms (37.1 MiB/s)
Retrieving file: /boot/Image
34484232 bytes read in 828 ms (39.7 MiB/s)
append: console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 iso
lcpus=1-2  video=tegrafb earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x1772e0000 gpt rootfs.slot_suffix= usbcore.old_scheme_first=1 t
egraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x175840000
 sdhci_tegra.en_boot_part_access=1  root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifname
s=0 isolcpus=1-2 
Retrieving file: /boot/kernel_tegra186-p3636-0001-p3509-0000-a01.dtb
192309 bytes read in 21 ms (8.7 MiB/s)
## Flattened Device Tree blob at 88400000
   Booting using the fdt blob at 0x88400000
ERROR: reserving fdt memory region failed (addr=0 size=0)
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 0000000088400000, end 0000000088431f34
copying carveout for /host1x@13e00000/display-hub@15200000/display@15200000...
copying carveout for /host1x@13e00000/display-hub@15200000/display@15210000...
copying carveout for /host1x@13e00000/display-hub@15200000/display@15220000...
DT property /chosen/nvidia,bluetooth-mac missing in source; can't copy
DT property /chosen/nvidia,wifi-mac missing in source; can't copy

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x100
[    0.000000] Linux version 4.9.253-tegra (buildbrain@mobile-u64-5497-d3000) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a
424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) ) #1 SMP PREEMPT Mon Jul 26 12:19:28 PDT 2021
[    0.000000] Boot CPU: AArch64 Processor [411fd073]
[    0.000000] OF: fdt:memory scan node memory@80000000, reg size 80,
[    0.000000] OF: fdt: - 80000000 ,  70000000
[    0.000000] OF: fdt: - f0200000 ,  85600000
[    0.000000] OF: fdt: - 175e00000 ,  200000
[    0.000000] OF: fdt: - 176600000 ,  200000

Some differences I’m spotting between the one you shared and branch 32.6.1 at nv-tegra.nvidia Code Review - 3rdparty/u-boot.git/commit are:

  1. Test u-boot binary loads extlinux dtb at 0x88400000, git u-boot loads it at 0x82400000
  2. Test u-boot binary says the board is a TX2 and not a TX2 NX:
    Test: Model: NVIDIA P2771-0000-500
    Git:
    U-Boot 2020.04 (Jun 22 2021 - 06:39:05 +0000)

    SoC: tegra186
    Model: NVIDIA P3636-0001
    Board: NVIDIA P3636-0001
    DRAM:  3.8 GiB
    MMC:   sdhci@3400000: 1, sdhci@3460000: 0
  1. Test u-boot doesn’t complain about not being able to copy ramoops_carveout. I don’t know if this is the root cause for the hang but these nodes were added in nv-tegra.nvidia Code Review - 3rdparty/u-boot.git/blobdiff - include/configs/tegra186-common.h

Thank you

hello AlexCo,

could you please check you’re having extlinux.conf.sig? please have a try to delete that if that file exist.

Hi @JerryChang , the extlinux.conf.sig file is not present in my setup.

However, the problem seems to be related to point 1) in my previous message. The test u-boot shared was compiled for the TX2, which allows for greater kernel image sizes than the TX2 NX. For the TX2 NX the size is still limited to 32MiB so the kernel and dtb overlap.

This patch solves the problem of loading device-trees trough extlinux.conf on the TX2 NX with the current revision in git:

From 2d170899c2ad9c3981028f3903045c022431c38d Mon Sep 17 00:00:00 2001
From: Alexandru Costache <alexc*@balena.io>
Date: Tue, 14 Dec 2021 13:36:41 +0100
Subject: [PATCH] p3636-0001: Increase kernel size on TX2 NX

Set TX2 NX kernel size to 128MiB,
same as for the TX2, in order to avoid kernel
hanging when loading a dtb from the filesystem.
Previously, the filesystem dtb in RAM and the
kernel overlapped, causing the kernel to hang
when loading any dtb trough extlinux.conf.

Upstream-status: Pending
Signed-off-by: Alexandru Costache <alexc*@balena.io>
---
 include/configs/p3636-0001.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/p3636-0001.h b/include/configs/p3636-0001.h
index 51c7af6a8b..bffca8348c 100644
--- a/include/configs/p3636-0001.h
+++ b/include/configs/p3636-0001.h
@@ -29,7 +29,7 @@
 		"ramdisk_addr_r\0" \
 	"kernel_addr_r_align=00200000\0" \
 	"kernel_addr_r_offset=00080000\0" \
-	"kernel_addr_r_size=02000000\0" \
+	"kernel_addr_r_size=08000000\0" \
 	"kernel_addr_r_aliases=loadaddr\0" \
 	"fdt_addr_r_align=00200000\0" \
 	"fdt_addr_r_offset=00000000\0" \
-- 
2.17.1

Can you please confirm if this is the correct approach? Thank you

Hi Alex,

I also ran in to the same kernel boot hang yesterday with the TX2 NX. I applied your patch to u-boot and flashed it, and I can confirm it resolved the hang.

1 Like

hello AlexCo,

yes, that’s correct patch to revise the DT loading failure.
please have the u-boot update to correct the issue on r32.6.1.

-       "kernel_addr_r_size=02000000\0" \
+       "kernel_addr_r_size=08000000\0" \

note, this fix had merged into the next release-32 code-line.
please expect next L4T public release (i.e. r32.7) will include the u-boot fix.
thanks

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.