TX2i can not boot on custom carrier board, but TX2 is ok. What's the difference between them?

Hi wm18822827507,

We had similar issue from other customer before and it turned out they have some extra device connected on board and cause the board draw more current, and then system hangs.

Could you check this part?

thank you ,i’ll try it.

I removed the external device, it doesn’t work. Is there any other way to debug this problem? This boot log contains too little information, I can’t guess what the problem is, This will take up too much of my time, and it won’t work.


Please set the new kernel cmdline as below. Remove all console interface and add “keep_bootcon” to see if you could see more logs.

CMDLINE_ADD="fbcon=map:0 net.ifnames=0 rootfstype=ext4 console=none keep_bootcon";

I modified bootargs of “kernel\hardware\nvidia\platform\t18x\quill\kernel-dts\tegra186-quill-p3489-1000-a00-00-base.dts” as below, Is that what you mean?.

  // bootargs ="console=ttyS0,115200 androidboot.presilicon=true firmware_class.path=/etc/firmware";
     bootargs ="fbcon=map:0 net.ifnames=0 rootfstype=ext4 console=none keep_bootcon";
        bootargs ="console=ttyS0,115200";

Just change it in p2771-0000.conf.common under your Linux_for_Tegra folder and reflash.

my TX2i can’t boot success., after change CMDLINE_ADD as below.

#Preformatted text`CMDLINE_ADD="console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0";
CMDLINE_ADD="fbcon=map:0 net.ifnames=0 console=none keep_bootcon";

Yes, because this step is just for debug and what we need to check is whether your boot up log has more hint now. There is no way to fix this issue by just modifying the kernel cmdline.

here the boot log.serial_2020-04-21_11-45-10.log (68.3 KB), Can you find any problems?

Current OEM DG in DLC is for TX2 series design including TX2i, there is a little difference on power part between TX2i and TX2 as you can see in Power-On Control section in it. Please check your custom design comparing to that. Also there is P2597 C02 board file of dev kit in DLC for your check.

thank you very much. I’ll check it.

Below is the boot log。 Is this the bootloader stage or the kernel loading stage?
Starting kernel …

[ 0.000000] Booting Linux on physical CPU 0x100
[ 0.000000] Linux version 4.9.140-tegra (buildbrain@mobile-u64-2988) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) ) #1 SMP PREEMPT Wed Mar 13 00:30:11 PDT 2019
[ 0.000000] Boot CPU: AArch64 Processor [411fd073]
[ 0.000000] OF: fdt:memory scan node memory@80000000, reg size 16416,
[ 0.000000] OF: fdt: - 80000000 , 70000000
[ 0.000000] OF: fdt: - f0200000 , 145600000
[ 0.000000] OF: fdt: - 235e00000 , 200000
[ 0.000000] OF: fdt: - 236600000 , 200000
[ 0.000000] OF: fdt: - 237000000 , 200000
[ 0.000000] earlycon: uart8250 at MMIO32 0x0000000003100000 (options ‘’)
[ 0.000000] bootconsole [uart8250] enabled
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb0_carveout’: base 0x0000000000000000, size 0 MiB
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb0_carveout’: base 0x0000000000000000, size 0 MiB
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb1_carveout’: base 0x0000000000000000, size 0 MiB
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb1_carveout’: base 0x0000000000000000, size 0 MiB
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb2_carveout’: base 0x0000000000000000, size 0 MiB
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb2_carveout’: base 0x0000000000000000, size 0 MiB
[ 0.000000] OF: reserved mem: initialized node ramoops_carveout, compatible id nvidia,ramoops
[ 0.000000] cma: Reserved 64 MiB at 0x00000000fc000000
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv1.0 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: MIGRATE_INFO_TYPE not supported.
[ 0.000000] psci: SMC Calling Convention v1.1
[ 0.000000] percpu: Embedded 23 pages/cpu @ffffffc1b6776000 s53400 r8192 d32616 u94208
[ 0.000000] Speculative Store Bypass Disable mitigation not required
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1764920
[ 0.000000] Kernel command line: root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2372e0000 gpt usbcore.old_scheme_first=1 tegraid= maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.983055.1 bl_prof_dataptr=0x10000@0x235840000 sdhci_tegra.en_boot_part_access=1 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4
[ 0.000000] log_buf_len individual max cpu contribution: 32768 bytes
[ 0.000000] log_buf_len total cpu_extra contributions: 163840 bytes
[ 0.000000] log_buf_len min size: 32768 bytes
[ 0.000000] log_buf_len: 262144 bytes
[ 0.000000] early log buf free: 29404(89%)
[ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.000000] Memory: 6942628K/7172096K available (15166K kernel code, 2914K rwdata, 6616K rodata, 8512K init, 605K bss, 163932K reserved, 65536K cma-reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffffff8000000000 - 0xffffff8008000000 ( 128 MB)
[ 0.000000] vmalloc : 0xffffff8008000000 - 0xffffffbebfff0000 ( 250 GB)
[ 0.000000] .text : 0xffffff8008080000 - 0xffffff8008f50000 ( 15168 KB)
[ 0.000000] .rodata : 0xffffff8008f50000 - 0xffffff80095d0000 ( 6656 KB)
[ 0.000000] .init : 0xffffff80095d0000 - 0xffffff8009e20000 ( 8512 KB)
[ 0.000000] .data : 0xffffff8009e20000 - 0xffffff800a0f8808 ( 2915 KB)
[ 0.000000] .bss : 0xffffff800a0f8808 - 0xffffff800a18fe3c ( 606 KB)
[ 0.000000] fixed : 0xffffffbefe7fd000 - 0xffffffbefec00000 ( 4108 KB)
[ 0.000000] PCI I/O : 0xffffffbefee00000 - 0xffffffbeffe00000 ( 16 MB)
[ 0.000000] vmemmap : 0xffffffbf00000000 - 0xffffffc000000000 ( 4 GB maximum)
[ 0.000000] 0xffffffbf00000000 - 0xffffffbf06dc8000 ( 109 MB actual)
[ 0.000000] memory : 0xffffffc000000000 - 0xffffffc1b7200000 ( 7026 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] Build-time adjustment of leaf fanout to 64.
[ 0.000000] RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=6.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=6
[ 0.000000] NR_IRQS:64 nr_irqs:64 0
[ 0.000000] GIC: Using split EOI/Deactivate mode
[ 0.000000] arm_arch_timer: Architected cp15 timer(s) running at 31.25MHz (phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xe6a171046, max_idle_ns: 881590405314 ns
[ 0.000003] sched_clock: 56 bits at 31MHz, resolution 32ns, wraps every 4398046511088ns
[ 0.009907] Console: colour dummy device 80x25
[ 0.014551] console [tty0] enabled
[ 0.018093] bootconsole [uart8250] disabled

When you see the log “Starting kernel …”, it is kernel log.

I don’t see much change here. Please still try to set console=none keep_bootcon to dump more log and see if this time the device gets stuck with new error.

serial_2020-04-27_15-52-13.log (136.6 KB)
I have set console=none keep_bootcon and Cut off all peripherals. Please help me to see what the problem is?

Do you use the same driver package for both devkit and your board?

yes, This is the same TX2i module

Hello , is anone here?

Excuse me, are you on holiday?

FYI, the driver package is not the module, so the earlier question refers to the flash software version. When flashing with JetPack/SDK Manager the GUI is just a front end to the “driver package”. Rephrased, a given driver package version is synonymous with the L4T version, and it is the driver package which does the work during a flash.

The list of L4T releases is here (you will need to go there, log in, and then click the link again):
…that left column of L4T is the same as the release version, and on an installed system you should see this from “head -n 1 /etc/nv_tegra_release”.

The URL which is the corollary to this and ties the JetPack/SDKM version to the L4T driver package version:

Do you see the same release from “head -n 1 /etc/nv_tegra_release” on both the TX2 and TX2i? This would also be reflected in the output from this on the host PC which performed the flash:

cd /where/ever/it/is/Linux_for_Tegra/rootfs/etc/
head -n 1 ./nv_tegra_release

Actually we still think it is a hardware design issue but no idea of the solution at this moment. Your TX2i is able to boot up when using same BSP on devkit, right?