R28.3.1 in Jetson Tx2 - booting stuck

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

HI,
I try to flash the Jetson Tx2 with Driver package R28.3.1, and extracted the same rootfs and did apply_binarires.sh.

I used the flash.sh script to flash. (I did not use jetpack)

After flashing, the board did not boot completely. It is stuck.

==================== Log Begins====================
U-Boot 2016.07-geb5c15bec5 (Jul 25 2019 - 03:58:50 -0700)

TEGRA186
Model: NVIDIA P2771-0000-500
DRAM: 7.8 GiB
MC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment

In: serial
Out: serial
Err: serial
Net: eth0: ethernet@2490000
Hit any key to stop autoboot: 0
MMC: no card present
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
213 bytes read in 77 ms (2 KiB/s)
p2771-0000 eMMC boot options
1: primary kernel
Enter choice: 1: primary kernel
Retrieving file: /boot/Image
34326536 bytes read in 867 ms (37.8 MiB/s)
append: root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=4

Flattened Device Tree blob at 92000000

Booting using the fdt blob at 0x92000000
reserving fdt memory region: addr=80000000 size=10000
Using Device Tree in place at 0000000092000000, end 000000009205f6f6

Starting kernel …

[ 0.000000] Booting Linux on physical CPU 0x100
[ 0.000000] Linux version 4.9.140-tegra (user-jrth@userjrth-Latitude-E6420) (gcc version 7.3.1 20180425 0
[ 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 , 185e00000
[ 0.000000] OF: fdt: - 276600000 , 200000
[ 0.000000] earlycon: uart8250 at MMIO32 0x0000000003100000 (options ‘’)
[ 0.000000] bootconsole [uart8250] enabled
[ 0.000000] Found tegra_fbmem2: 00800000@969f0000
[ 0.000000] Found lut_mem2: 00002008@969ed000
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb0_carveout’: base 0x0000000000B
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb0_carveout’: base 0x0000000000B
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb1_carveout’: base 0x0000000000B
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb1_carveout’: base 0x0000000000B
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb2_carveout’: base 0x0000000000B
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb2_carveout’: base 0x0000000000B
[ 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.0
[ 0.000000] percpu: Embedded 25 pages/cpu @ffffffc1f5f6a000 s61592 r8192 d32616 u102400
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2024032
[ 0.000000] Kernel command line: root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 OS=4
[ 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: 29348(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: 7970168K/8224768K available (15294K kernel code, 2930K rwdata, 6660K rodata, 8576K i)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffffff8000000000 - 0xffffff8008000000 ( 128 MB)
[ 0.000000] vmalloc : 0xffffff8008000000 - 0xffffffbebfff0000 ( 250 GB)
[ 0.000000] .text : 0xffffff8008080000 - 0xffffff8008f70000 ( 15296 KB)
[ 0.000000] .rodata : 0xffffff8008f70000 - 0xffffff8009600000 ( 6720 KB)
[ 0.000000] .init : 0xffffff8009600000 - 0xffffff8009e60000 ( 8576 KB)
[ 0.000000] .data : 0xffffff8009e60000 - 0xffffff800a13c808 ( 2931 KB)
[ 0.000000] .bss : 0xffffff800a13c808 - 0xffffff800a1d4dfc ( 610 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 - 0xffffffbf07da0000 ( 125 MB actual)
[ 0.000000] memory : 0xffffffc000000000 - 0xffffffc1f6800000 ( 8040 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: s
[ 0.000003] sched_clock: 56 bits at 31MHz, resolution 32ns, wraps every 4398046511088ns
[ 0.009964] Console: colour dummy device 80x25
[ 0.014625] console [tty0] enabled
[ 0.018180] bootconsole [uart8250] disabled
==================== Log Ends====================

The HDMI display shows only nvidia logo and stuck.

WHy is that? How can I recover without JetPack installation.

-Jay

2

Those basics are correct, but I’m not sure if the details were. What I’ll suggest is flashing again, but I’ll add details. Realize that a VM will usually fail due to USB issues and is not supported (some people get USB to pass through correctly, but often this takes work on VM configuration). The general steps:

  1. Unpack the driver package without sudo.
  2. Go to “Linux_for_Tegra” and unpack with sudo (“sudo tar xvfp /where/ever/sample_rootfs.tbz2”).
  3. cd back up to “Linux_for_Tegra”.
  4. Run apply_binaries.sh with sudo (“sudo ./apply_binaries.sh”)
  5. Put the Jetson in recovery mode with micro-B USB connected.
  6. Verify USB with “lsusb -d 0955:7c18”.
  7. Flash without logging:
    sudo ./flash.sh jetson-tx2 mmcblk0p1
  8. Or, flash with logging:
    sudo ./flash.sh jetson-tx2 mmcblk0p1 2>&1 | tee log_flash.txt

If this still fails, then uploading the flash log would help. You will also want to specify if this is using the dev kit carrier board, or if it is from a third party carrier board since a different carrier board needs extra support files.

3

Hi,
I followed the steps as you mentioned.
I am using the Jetson Tx2’s carrier board. I use Ubuntu 18.04 host machine to flash the Jetson with R28
The log file here.

FLASH log-R28-jetsontx2.log (424.7 KB)

4

The flash was successful, and unless some of the content was incorrect (which is very unlikely), then the unit should work. With the new flash, does the serial console log of boot end the same?

The next thing you should have seen on serial console was something like this:
[ 0.000000] Booting Linux on physical CPU 0x100

So it halts right as the more interesting content should start. There may be an actual hardware failure, and I hate to say it, but you should probably try flashing another release just to see if it works (you could still go back to the R28.3.1 release). I see nothing in the logs which would indicate a software reason for halting where does.

5

Hi @linuxdev,
I can see the
“Booting Linux on physical CPU 0x100” in the console message.
Also I flashed the R32.3 version of software, and it works fine in the hardware. So no hardware issue.
I need to test Ubuntu16.04 version, thats why used R28.xx. Any other version that I can use to test Ubuntu 16.04?

regards,
JK

6

All of the R28.x series should be Ubuntu 16.04 LTS. The most recent in that series is R28.3.2:
https://developer.nvidia.com/embedded/linux-tegra-r2832

To use this you would run a command line flash after setting up the “driver package” and “sample root filesystem”. JetPack3.3.1 could then be run after disabling the “flash” step, and the optional packages added through that, e.g., CUDA.

There were some L4T patch releases which did not release a new JetPack because they were compatible between the older JetPack and the patched rootfs.

Command line flash is fairly simple if you are interested in that. You’d unpack the tarball of the driver package as a regular user, go into the “Linux_for_Tegra/rootfs/” location, unpack the “sample rootfs” with sudo, cd back up to the “Linux_for_Tegra/” directory, and then run “sudo ./apply_binaries.sh”. After that you could flash any time you want via:
sudo ./flash.sh jetson-tx2 mmcblk0p1

Account names exist by default in those earlier releases, and so after verifying you have ssh access, you could then run JetPack3.3.1, uncheck flash, and then pick what packages you want to install to the Jetson over ssh.

7

I have taken R28.3.2 BSP and flashed without issue. But “lspci” does not output the devices list. Updated the ODMDATA=0x90000 in
p2771-0000.conf.common.

8

Hi yajforforum,

What is your purpose of using rel-28.3.2 here? You have another topic there to track m.2 card issue on rel-32.4.2.
Are you checking the same issue with different topics?

9

I don’t know about any effect of ODMDATA for PCI (this could be related by I don’t not know).

Btw, lspci only shows devices detected during boot. If no devices are detected, then the bus power will shut down. Not even the bridge will show. An example is that an FPGA which does not boot in time to respond to queries as the Jetson boots will not show up even if it is valid hardware…a case where one would have to boot the FPGA first to see it on lspci. Or the Jetson could be modified to allow delayed detection.

Bad signal quality during boot could also eliminate a PCIe device and lspci would ignore it. You need a serial console boot log from prior to the Linux kernel even loading to know about the early content.

10

Not the same issue Wayne.
I was testing a issue and there needed R28x version.
But it got stuck. I want to trace this R28.x issue seperately, as I moved to another part of work. I try this R28 in different Jetson board. Thats why put in seperate thread.

Is R28.x still supported or not?

JK

11

Yes, it is still supported. But actually I don’t use it very often now.
The ODMDATA method should work. You could firstly try with devkit to verify ODMDATA first.