Uboot Fails to Load Kernel TK1

Robotics & Edge Computing Jetson & Embedded Systems Jetson TK1
, ,
1

Hi,
I am working with a customized board based on Jetson TK1. I am able to flash the L4T drivers/OS into the board successfully but the flashed u-boot gets stuck before it can start the kernel.
I am following the steps given in the link:
Jetson TK1 - NvError 0x120002 - #8 by linuxdev
I downloaded the driver package and trusty’s sample rootfile system from the following link:
https://developer.nvidia.com/linux-tegra-r218
The host PC is Ubuntu 16 running on a VM. I modified the EMMCSIZE and ROOTFSSIZE parameters to:
EMMCSIZE=31272730624;
ROOTFSSIZE=30538727424;
in the jetson-tk1.conf file according to the eMMC used on my board which is a SWISSBIT 32GB eMMC JEDEC 5.0 compliant, model number:
SFEM032GB1EA1TO-I-HG-12P-STD
The flash command I am using is “sudo ./flash.sh jetson-tk1 mmcblk0p1”.
Here is the Flash and Boot Log file:

[0000.000] [TegraBoot] (version UNDEF_BUILD)
[0000.004] Reset reason: power on reset
[0000.008] Processing in recovery mode
[0000.011] Established communication link with host
[0001.328] Downloaded bct successfully
[0001.343] No Battery Present
[0001.347] Sdram initialization is successful
[0001.416] Downloaded DTB successfully
[0001.442] No Battery Present
[0002.029] Downloaded bootloader successfully
[0002.033] CPU-bootloader entry address: 0x83d88000
[0002.037] BoardId: 375
[0002.039] Vpr Carveout Base=0x0f4600000 Size=0x00ba00000
[0002.045] Tsec Carveout Base=0x0f2600000 Size=0x002000000
[0002.050] Lp0 Carveout Base=0x0f25ff000 Size=0x000001000
[0002.055] Xusb Carveout Base=0x0f2300000 Size=0x000200000
[0002.060] Platform-DebugCarveout: 0
[0002.087] CPU power rail is up
[0002.090] Performing RAM repair
[0002.093] CPU clock init successful
[0002.096] Starting CPU & Halting co-processor
NVRM Initialized shmoo database
NVRM CLOCKS: PLLX0: 696000 Khz
NVRM CLOCKS: PLLM0: 924000 Khz
NVRM CLOCKS: PLLC0: 0 Khz
NVRM CLOCKS: PLLP0: 408000 Khz
NVRM CLOCKS: PLLA0: 11289 Khz
NVRM CLOCKS: CPU: 696000 Khz
NVRM CLOCKS: AVP: 48000 Khz
NVRM CLOCKS: System Bus: 48000 Khz
NVRM CLOCKS: Memory Controller: 924000
NVRM CLOCKS: External Memory Controller: 924000
EEPROM instance-5: Querying board info from BCT.
EEPROM instance-0: Querying board info from BCT.
EEPROM instance-0: No board info available for this instance in BCT.
EEPROM instance-1: Querying board info from BCT.
EEPROM instance-1: Board info present in BCT is invalid.
EEPROM instance-2: Querying board info from BCT.
EEPROM instance-2: No board info available for this instance in BCT.
EEPROM instance-3: Querying board info from BCT.
EEPROM instance-3: No board info available for this instance in BCT.
EEPROM instance-4: Querying board info from BCT.
EEPROM instance-4: Board info present in BCT is invalid.
EEPROM instance-5: Querying board info from BCT.
EEPROM instance-5: BoardInfo: 0xffff:0xffff:0375:0000:03:EEPROM instance-6: Querying board info from BCT.
EEPROM instance-6: BoardInfo: 0xffff:0xffff:0375:0000:03:EEPROM instance-7: Querying board info from BCT.
EEPROM instance-7: No board info available for this instance in BCT.
Final BoardID: proc: 375 and pmu 375
ADJUSTED CLOCKS:
MC clock is set to 924000 KHz
EMC clock is set to 924000 KHz (DDR clock is at 924000 KHz)
PLLX0 clock is set to 696000 KHz
PLLC0 clock is set to 0 KHz
CPU clock is set to 696000 KHz
System and AVP clock is set to 48000 KHz
GraphicsHost clock is set to 163200 KHz
MSENC clock is set to 92400 KHz
Vde clock is set to 204000 KHz

Bootloader-Cpu Init at (time stamp): 233743739 us

Pinmux changes applied in kernel way

[bootloader] (version UNDEF_BUILD)
Platform Pre Boot configuration…
NvDdkUsbhBlockDevInit…
Initializing Display
The proc BoardInfo: 0x0177:0x0000:0x03:0x00:0x00
The proc BoardInfo: 0x0177:0x0000:0x03:0x00:0x00
This Pmu Module is not present.
The best display mode is 2560x1600/60Hz, pclk: 268627Khz

DSI PAD calibration done

DSI PAD calibration done

DSI PAD calibration done

DSI PAD calibration done
Entering NvFlash recovery mode / Nv3p Server

Nv3pServer Version 4.13.0000

: DecodeCSD:
: readBlkBits=9, readBlkSize=512 Bytes
: nSectors=(CSIZE+1)(2(CSizeMult+2))=4096 * 512 = 2097152 Sectors
: writeBlkBits=9, writeBlkSize=512 Bytes
: ERASE_GRP_SIZE=31, ERASE_GRP_MULT=31
: EraseGrpSize=(31+1)*(31+1)=1024 Sectors (524288 Bytes)
: WPGrpSize=15360 Sectors (7864320 Bytes)
***: ReadExtCSD:
: overriding USER Sectors = 61079552 Sectors
: keep CSD EraseGrpSize = 1024 Sectors (524288 Bytes)
: keep CSD WPGrpSize = 15360 wBlks (7864320 Bytes)
: BootPartSize = 4194304 Bytes (8192 Sectors)
***: SetBlockSize to 512 Bytes SKIPPED because CMD16 is illegal for DDR50…
***: SdGetDevInfo: PagesPerBlock = 32 pages (256 Sectors)
***: SdGetDevInfo: TotSecs=TotBlk(238656)*PgPerBlk(32)*SecsPerPg(8)=61095936
Region=1 SD Erase start 512B-sector=0,512B-sector-num=8192
Region=2 SD Erase start 512B-sector=0,512B-sector-num=8192
Region=0 SD Erase start 512B-sector=0,512B-sector-num=61079552
SD Alloc Partid=2, start sector=0,num=2048
SD Alloc Partid=3, start sector=2048,num=512
SD Alloc Partid=4, start sector=2560,num=512
SD Alloc Partid=5, start sector=3072,num=1024
SD Alloc Partid=6, start sector=4096,num=4096
SD Alloc Partid=7, start sector=8192,num=1536
SD Alloc Partid=8, start sector=9728,num=512
SD Alloc Partid=9, start sector=10240,num=1536
SD Alloc Partid=10, start sector=11776,num=1536
SD Alloc Partid=11, start sector=13312,num=512
SD Alloc Partid=12, start sector=13824,num=7455744
SD Alloc Partid=13, start sector=7469568,num=1024
SD Alloc Partid=14, start sector=7470592,num=16384
SD Alloc Partid=15, start sector=7486976,num=1024
SD Alloc Partid=16, start sector=7488000,num=1024
SD Alloc Partid=17, start sector=7489024,num=1024
SD Alloc Partid=18, start sector=7490048,num=1024
SD Alloc Partid=19, start sector=7491072,num=512
SD Alloc Partid=20, start sector=7491584,num=144896
SD Alloc Partid=21, start sector=7636480,num=512
Region=0 SD Erase start 512B-sector=4096,512B-sector-num=4096
Start Downloading PPT
Parallel write enabled

End Downloading PPT
Time taken to download partition: 2151 ms

Start Downloading EBT

End Downloading EBT
Time taken to download partition: 784 ms

Start Downloading APP

End Downloading APP
Time taken to download partition: 2045780 ms

Start Downloading DTB

End Downloading DTB
Time taken to download partition: 81 ms

Start Downloading GPT

End Downloading GPT
Time taken to download partition: 2114 ms
WriterThread: Exiting
Rebooting device after flashing.

U-Boot SPL 2018.05-gc50329da15 (Oct 31 2019 - 13:48:20 -0700)
Trying to boot from RAM

U-Boot 2018.05-gc50329da15 (Oct 31 2019 - 13:48:20 -0700)

TEGRA124
Model: NVIDIA Jetson TK1
Board: NVIDIA Jetson TK1
DRAM: 2 GiB
MMC: sdhci@700b0400: 1, sdhci@700b0600: 0
Loading Environment from MMC… *** Warning - bad CRC, using default environment

Failed (-5)
In: serial
Out: serial
Err: serial
CPU is in NS mode
Net: No ethernet found.
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
827 bytes read in 3235 ms (

The uboot gets stuck at the last 2 lines:
Retrieving file: /boot/extlinux/extlinux.conf
827 bytes read in 3235 ms (
Also next time I reset the device it always get stuck at the 5th last line :
mmc0(part 0) is current device
What am I missing?

2

Hard to say, but can you post the content of the extlinux.conf file? The fact that it found the file tends to say that up till now things have gone well.

4

Thanks for the quick reply. Here is the content inside the extlinux.conf file from the Linux_for_Tegra/rootfs/boot/extlinux Folder:

TIMEOUT 30
DEFAULT primary

MENU TITLE Jetson-TK1 eMMC boot options

LABEL primary
MENU LABEL primary kernel
LINUX /boot/zImage
FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt

5

For reference, this is R21.8, but I only have logs for older R21.6 boot. Should be the same.

I am somewhat guessing at this, but I think what is going on is that the kernel is starting to load, but whatever code is being pointed at to start running the kernel is hanging. This tends to happen when the kernel or some other related code (perhaps an initrd) has something quite wrong. At this point I don’t think the kernel or initrd would be wrong releases, but that is one example of when it might do this; another example being when the boot code can’t handle a compressed zImage kernel, and can only handle an uncompressed Image kernel. Your extlinux.conf specifies a zImage, but so far as I know 100% of all 32-bit kernels work (and are intended) to use the compressed zImage. Those examples are not why it would fail for your case, but I mention them as a “theme”.

I am thinking that something in your modification of EMMCSIZE and ROOTFSSIZE would be invalid, and the kernel just hangs when using the wrong disk config, or else the modification itself just isn’t handled correctly by the flash software.

Can you provide details about the hardware itself? Normally a dev kit would never have memory changed (it is soldered to the board), and it would be useful to know how your carrier board differs from the dev kit board down to fine details.

Next, can you flash twice, once using modified commands as you have, and once with defaults used for the stock dev kit without modifications? Then post the logs of both flashes, and also how the unit behaves (boot log) when booting to the non-modified config? If you append this to the flash command, then it will log: " 2>&1 | tee logfile.txt".

So for the “non-modified” flash with all software being stock to the TK1 dev kit it would be something like this:
sudo ./flash.sh jetson-tk1 mmcblk0p1 2>&1 | tee log_unmodiifed.txt
(then you could attach file “log_unmodified.txt”)

Similarly, for modified, after you’ve edited configs for EMMCSIZE and ROOTFSSIZE:
sudo ./flash.sh jetson-tk1 mmcblk0p1 2>&1 | tee log_modified_emmcsize_rootfssize.txt
(and attach the log to the forum thread)

The flash log will say more about what was done with partitioning and choosing content to flash.

6

I see. I will try out your recommendations and share the log files ASAP.

Also another thing I would like to bring into your notice is that I have also tried to flash R21.6 drivers with its default uboot downloaded from the link:
(https://developer.nvidia.com/linux-tegra-r216)

Unexpectedly the results are different as you can see from the log file shared below:

Rebooting device after flashing.

U-Boot SPL 2014.10-rc2-gb1d8a75 (Oct 13 2017 - 18:01:57)

U-Boot 2014.10-rc2-gb1d8a75 (Oct 13 2017 - 18:01:57)

TEGRA124
Board: NVIDIA Jetson TK1
I2C: ready
DRAM: 2 GiB
MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
mmc_send_cmd_bounced: MMC Timeout
Interrupt status 0x00000001
Interrupt status enable 0xffff003b
Interrupt signal enable 0xffff0002
Present status 0x01fb02f6
mmc_wait_inhibit: timeout error
mmc_send_cmd_bounced: MMC Timeout
Interrupt status 0x00000001
Interrupt status enable 0xffff003b
Interrupt signal enable 0xffff0002
Present status 0x01fb02f6
mmc_send_cmd_bounced: error during transfer: 0x00108001
mmc_send_cmd_bounced: MMC Timeout
Interrupt status 0x00000001
Interrupt status enable 0xffff003b
Interrupt signal enable 0xffff0002
Present status 0x01fb02f6
mmc_wait_inhibit: timeout error
Using default environment

tegra-pcie: PCI regions:
tegra-pcie: I/O: 0x12000000-0x12010000
tegra-pcie: non-prefetchable memory: 0x13000000-0x20000000
tegra-pcie: prefetchable memory: 0x20000000-0x40000000
tegra-pcie: 2x1, 1x1 configuration
tegra-pcie: probing port 0, using 2 lanes
tegra-pcie: link 0 down, retrying
tegra-pcie: link 0 down, retrying
tegra-pcie: link 0 down, retrying
tegra-pcie: link 0 down, ignoring
tegra-pcie: probing port 1, using 1 lanes
tegra-pcie: link 1 down, retrying
tegra-pcie: link 1 down, retrying
tegra-pcie: link 1 down, retrying
tegra-pcie: link 1 down, ignoring
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0
MMC: no card present
mmc_send_cmd_bounced: MMC Timeout
Interrupt status 0x00000001
Interrupt status enable 0xffff003b
Interrupt signal enable 0xffff0002
Present status 0x01fb02f6
mmc_wait_inhibit: timeout error
mmc_send_cmd_bounced: MMC Timeout
Interrupt status 0x00000001
Interrupt status enable 0xffff003b
Interrupt signal enable 0xffff0002
Present status 0x01fb02f6
mmc_send_cmd_bounced: error during transfer: 0x00108001
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0…
** No partition table - mmc 0 **
** No partition table - mmc 0 **
** No partition table - mmc 0 **
** No partition table - mmc 0 **
** No partition table - mmc 0 **
** No partition table - mmc 0 **
(Re)start USB…
USB0: USB EHCI 1.10
scanning bus 0 for devices… 1 USB Device(s) found
USB1: USB EHCI 1.10
scanning bus 1 for devices… 1 USB Device(s) found
scanning usb for storage devices… 0 Storage Device(s) found
scanning usb for ethernet devices… 0 Ethernet Device(s) found

USB device 0: unknown device
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-tegra124
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
No ethernet found.
Tegra124 (Jetson TK1) #
Tegra124 (Jetson TK1) # run bootcmd
MMC: no card present
mmc_send_cmd_bounced: MMC Timeout
Interrupt status 0x00000001
Interrupt status enable 0xffff003b
Interrupt signal enable 0xffff0002
Present status 0x01fb02f6
mmc_wait_inhibit: timeout error
mmc_send_cmd_bounced: MMC Timeout
Interrupt status 0x00000001
Interrupt status enable 0xffff003b
Interrupt signal enable 0xffff0002
Present status 0x01fb02f6
mmc_send_cmd_bounced: error during transfer: 0x00108001
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0…
** No partition table - mmc 0 **
** No partition table - mmc 0 **
** No partition table - mmc 0 **
** No partition table - mmc 0 **
** No partition table - mmc 0 **
** No partition table - mmc 0 **
(Re)start USB…
USB0: USB EHCI 1.10
scanning bus 0 for devices… 1 USB Device(s) found
USB1: USB EHCI 1.10
scanning bus 1 for devices… 1 USB Device(s) found
scanning usb for storage devices… 0 Storage Device(s) found
scanning usb for ethernet devices… 0 Ethernet Device(s) found

USB device 0: unknown device
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-tegra124
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
No ethernet found.
Tegra124 (Jetson TK1) #

The device enters uboot shell mode every time it powers up. What are your thoughts on this?

7

Hi, I followed your instructions and here are the results:
1- Log file for unmodified R21.8 software where default settings for EMMCSIZE & ROOTFSSIZE are used:

log_unmodified.txt (88.0 KB)

2- Log file for modified R21.8 software where EMMCSIZE=31272730624 & ROOTFSSIZE=30538727424 set in the jetson-tk1.conf file:

log_modified_emmcsize_rootfssize.txt (89.3 KB)

I have added the Boot Logs as seen on debug UART at the end of both files. Again the uboot get stuck at the lines :
Scanning mmc 0:1…
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
827 bytes read in 3235 ms (

Looking forward.

8

I just wanted to say ahead of time that the short version of all of what is below is about these simple questions:

  • Is the device tree tegra124-jetson_tk1-pm375-000-c00-00.dtb correct? If you placed this directly into “roots/boot/” prior to flash, then it will be wrong since flash.sh itself copies its version in prior to creating an image.
  • Similarly, flash.sh copies zImage into “rootfs/boot/” prior to flash. If you copied your own zImage into “rootfs/boot/”, then flash.sh would overwrite this with its own version.
  • Any such “rootfs/boot/” content needs to be modified where the driver package has the content so that the driver package will copy in to rootfs your version for cases where your version is modified.
  • The big long explanation is just talking about the above. Most of what is written below is probably not necessary, but I include it because I cannot watch you set up and flash to verify anything.

When U-Boot results in entering the shell, or trying to use PXE, this implies U-Boot could not find the boot content (your post #5). Post #5 differs from your original post because original post shows boot could find a kernel (not finding the kernel is different from loading a kernel but not getting execution to continue). Something about how you flashed in that post was incomplete, otherwise a kernel and/or extlinux.conf would have been found.

You cannot change just the bootloader (unless you know how to edit for changes) and have it work on most embedded systems (there is no BIOS) since finding the content to boot is not automatic (content must be explicitly named, and no search function exists…searching implies switching to finding the content on other media). Missing that content results in attempting other boot methods, e.g., the PXE instead of eMMC. Thus I wonder if perhaps the driver package and rootfs might be from different releases.

For reference, this appears to be the “.dtb” file which is both flashed and found:
tegra124-jetson_tk1-pm375-000-c00-00.dtb
(I am leaning towards finding out if this is the device tree which applies to your custom carrier board)

Likely a change in just the bootloader (versus complete flash) relies on different kernel or other file names versus what is found in a given rootfs. One thing which is subtle, but important, is that the act of running “flash.sh”, just prior to building the system.img, will copy a kernel and device tree and extlinux.conf into the “rootfs/boot” area. Thus any missing boot content (such that the bootloader continues on to try PXE boot) could be from mixing what flash.sh installs versus something else being expected. In any of these cases are you certain that the expected device tree and kernel zImage the bootloader looks for are the same as what is found in “rootfs/boot”? If you placed these yourself into “rootfs/boot”, then the flash.sh script would have overwritten them with the version found in the driver package subdirectories.

Expanding on that topic, are you performing a complete flash with all content from the same release (probably so, but I have to ask before continuing)? For example, in some cases the patch release can use the older driver package, but if the release comes with a driver package, then you must use the same driver package release the rootfs release. It is good to try R21.6, but only if you flashed everything with that release.

The “log_unmodified.txt” does not appear to start at the beginning of flash. It only shows the part where it is building rootfs and later. Is this the whole log? I could be wrong about that since it is so old, but from what I recall there should be more log content prior to starting the system.img build from the flash.sh script. I will say though that what is there looks correct (and perhaps what is there is all there is).

Restating the extlinux.conf you named in #3 for reference:

    TIMEOUT 30
    DEFAULT primary

    MENU TITLE Jetson-TK1 eMMC boot options

    LABEL primary
    MENU LABEL primary kernel
    LINUX /boot/zImage
    FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
    APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt

Once “log_unmodified.txt” completes flash and reboots the error is seen at about the same place where “extlinux.conf” is found, but boot never continues. I don’t know what this “Failed (-5)” U-Boot error is (someone from NVIDIA would have to look up the “-5” error), but perhaps it is related to failure to continue and failure to find "/boot/zImage"as named in the extlinux.conf of #3:

Failed (-5)
In:    serial
Out:   serial
Err:   serial

I do see this though, so it must be at least partially correct:

mmc0(part 0) is current device
Scanning mmc 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
827 bytes read in 2369 ms (

Whatever “log_umodified.txt” is trying to do with what it found in “extlinux.conf” is failing. Probably the kernel itself cannot be found, but possibly it is device tree (or both).

Mostly the “log_modified_emmcsize_rootfssize.txt” appears to be valid. Look closely at that log for any occurrence of a “.dtb” file (those are device tree). Can you verify that the named “.dtb” is what your extlinux.conf names (if named there), and that this is modified to work with your customized carrier board? It is possible that the kernel would not be able to continue if the device tree is incorrect, although I suspect an incorrect “.dtb” could cause a kernel to just stop booting (not likely that the kernel would not at least print some content before halting, but slightly possible).

10

Hi,
Could you explain/suggest why does the uboot image from the R21.6 fails at the function mmc_send_cmd_bounced which seems to be related to the initial process of initializing the emmc. The function is in /drivers/mmc/tegra_mmc.c file. Some relevant portion of the function is :

else if (get_timer(start) > 2000UL) {
writel(mask, &host->reg->norintsts);
printf(“%s: MMC Timeout\n”
" Interrupt status 0x%08x\n"
" Interrupt status enable 0x%08x\n"
" Interrupt signal enable 0x%08x\n"
" Present status 0x%08x\n",
func, mask,
readl(&host->reg->norintstsen),
readl(&host->reg->norintsigen),
readl(&host->reg->prnsts));
return -1;
}

Similarly, the ‘** No partition table - mmc 0 **’ print is found in the get_device_and_partition function from /disk/part.c file:

  • No partition table on device,

  • or user requested partition 0 (entire device).
    */
    if (((dev_desc)->part_type == PART_TYPE_UNKNOWN) ||
    (part == 0)) {
    if (!(dev_desc)->lba) {
    printf("     Bad device size - %s %s **\n", ifname,
    dev_str);
    goto cleanup;
    }

    /*

    • If user specified a partition ID other than 0,
    • or the calling command only accepts partitions,
    • it’s an error.
      /
      if ((part > 0) || (!allow_whole_dev)) {
      printf("      * No partition table - %s %s **\n", ifname,
      dev_str);
      goto cleanup;
      }

I am currently flashing R21.6 drivers and getting these prints. But if i flash the R21.8 uboot keeping everything else the same from R21.6 i.e. kernel, rootfile system, dtb, the new uboot is somehow able to detect/initialize emmc and finds extlinux.conf file but then gives some other error related to FTD.

My question is regarding No partition Table found error and mmc_send_cmd_bounce errors. What could be the reasons for these errors and why are they resolved (it seems so) when using upgraded R21.8 uboot image?

11

For reference, the above starts at line 295 in the U-Boot source. That code is apparently just a timer, and I don’t really have a way at guessing why it timed out.

I am speculating, but the code from part.c is probably there because the device must contain other partitions. No partition and using the whole device would not allow this, and no partition table also would be a sanity check that the device could contain the mandatory multiple partition setup a TK1 uses. Don’t know for sure though. The partition layout itself would have more restrictions in the earlier Jetsons that it does in the newer ones, but even now there are restrictions on device partition layout. It is likely that there were different layout requirements between R21.6 and R21.8, or else there was a bug fix.

Someone else with more knowledge of the bootloader layout will need to answer this:

My own thought on this is that hardware for hardware drivers must be found before devices can be used, and that it is very likely the hardware is not accessible at the time required. One reason for this is not having the device correctly set up in device tree, and another reason might be a related device not being set up. The related devices might include a power rail or a clock used by that device. It is true that hardware design itself could cause this, but the device tree is complicated enough that it is easy to overlook a software setup item as well.