Our custome board is designed based on the Jetson TK1 board, but failed in rebooting after flashing.
Below is the last three lines printed on ubuntu.
*** The target ardbeg has been flashed successfully. ***
Make the target filesystem available to the device and reset the board to boot from external mmcblk1p1.
Below is the last part printed by serial console.
End Downloading GPT
Time taken to download partition: 193 ms
WriterThread: Exiting
Rebooting device after flashing
The serial console stuck at rebooting and the board stuck at USB RCM mode.
In our custom board, AVDD_DSI_CSI and VDDIO_HSIC are left open because all of the pins on these two power-rails are unused. Would that be the reason caused rebooting failure?
It seems right that the GPIO_P10( AP_FORCE_RECOVERY_L) keeps high when only reset button is asserted. The power sequence is the same with Jetson TK1. Is there any other suggestions on this problem? Thanks!
Thanks!
The flash was apparently to mmcblk1p1, the SD card. Was there an SD card present, and did that SD card have the extlinux file and root partition on it? This could be the issue if it is purely software and not hardware-related.
Yes, the flash was to mmcblk1p1.
I input the same script to Jetson TK1 and it boot automatically after flashing even if the SD card was not present.
I input the command sodu ./flash.sh -S 14GiB jetson_tk1 mmcblk0p1 and the problem is the same.
Below is the printed messange on ubuntu and the serial console print the same thing as before.
*** Flashing target device started. ***
./nvflash --boardid 0x177 0x00 0x03 --bct CFG_102MHz.cfg --setbct --configfile flash.cfg --create --bl fastboot.bin --odmdata 0x6009C000 --go
Nvflash 4.13.0000 started
BR_CID: 0x340010017410b102200000000cff8480
rcm version 0X400001
Skipping BoardID read at miniloader level
System Information:
chip name: unknown
chip id: 0x40 major: 1 minor: 1
chip sku: 0x0
chip uid: 0x000000017410b102200000000cff8480
macrovision: disabled
hdcp: disabled
jtag: disabled
sbk burned: false
board id: 0
warranty fuse: 0
dk burned: false
boot device: emmc
operating mode: 3
device config strap: 0
device config fuse: 0
sdram config strap: 0
RCM communication completed
auxInfo->NCTBoardInfo->proc_board_id is 375
auxInfo->NCTBoardInfo->proc_sku is 0
auxInfo->NCTBoardInfo->proc_fab is 3
BCT sent successfully
sending file: tegra124-jetson_tk1-pm375-000-c00-00.dtb
- 59637/59637 bytes sent
tegra124-jetson_tk1-pm375-000-c00-00.dtb sent successfully
odm data: 0x6009c000
downloading bootloader -- load address: 0x83d88000 entry point: 0x83d88000
sending file: fastboot.bin
- 594363/594363 bytes sent
fastboot.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
ML execution and Cpu Handover took 1 Secs
Partition backup took 0 Secs
setting device: 2 3
deleting device partitions
creating partition: BCT
creating partition: PPT
creating partition: PT
creating partition: EBT
creating partition: LNX
creating partition: SOS
creating partition: NVC
creating partition: MPB
creating partition: MBP
creating partition: GP1
creating partition: APP
creating partition: DTB
creating partition: EFI
creating partition: USP
creating partition: TP1
creating partition: TP2
creating partition: TP3
creating partition: WB0
creating partition: UDA
creating partition: GPT
sending file: ppt.img
\ 2097152/2097152 bytes sent
ppt.img sent successfully
padded 12 bytes to bootloader
sending file: u-boot.bin
- 440016/440016 bytes sent
u-boot.bin sent successfully
sending file: system.img
| 2372264844/2372264844 bytes sent
system.img sent successfully
sending file: tegra124-jetson_tk1-pm375-000-c00-00.dtb
- 59637/59637 bytes sent
tegra124-jetson_tk1-pm375-000-c00-00.dtb sent successfully
sending file: gpt.img
\ 2097152/2097152 bytes sent
gpt.img sent successfully
Create, format and download took 497 Secs
Time taken for flashing 500 Secs
*** The target ardbeg has been flashed successfully. ***
Reset the board to boot from internal eMMC.
Your log is quite different from what I get under R21.4 flash (at least in the early stages)…I don’t see error, but the difference is odd. Which L4T version did you use?
NOTE: One of the most interesting differences is that my board has an nvflash command for Hynix memory for bct, your bct entry is quite different.
Yes, I uncommented the BOARD_ID in jetson-tk1.conf as our custom board has no EEPROM.
Besides I degrated the SDRAM speed to increase margin of timing. Maybe this is where the log difference come from.
The L4T version is R21.4.
I tried the BCT with PM375_Hynix_2GB_H5TC4G63AFR_RDA_792MHz.cfg and the problem is still present.
Below is part of the jetson-tk1.conf codes.
############################################################################
# Standard ENV variables:
############################################################################
# ODMDATA for USB2.0 configuration on USB port(J1C2 connector) = 0x6009C000
# ODMDATA for USB3.0 configuration on USB port(J1C2 connector) = 0x6209C000
ODMDATA=0x6009C000;
BOOTPARTSIZE=8388608;
EMMCSIZE=15766388736;
ROOTFSSIZE=15032385536;
SYSBOOTFILE=jetson-tk1_extlinux.conf;
BOOTLOADER=bootloader/ardbeg/u-boot.bin
############################################################################
# .conf file only variables:
############################################################################
#EMMC_BCT=PM375_Hynix_2GB_H5TC4G63AFR_RDA_792MHz.cfg;
EMMC_BCT=CFG_102MHz.cfg
#EMMC_BCT=Hynix_2GB_H5TC4G63AFR-RDA_300MHz.cfg;
EMMC_CFG=gnu_linux_fastboot_emmc_full.cfg;
DTB_FILE=tegra124-jetson_tk1-pm375-000-c00-00.dtb;
CMDLINE_ADD="fbcon=map:1";
UBOOT_TEXT_BASE=0x81008000;
NET_BSF=ardbeg_net.hush;
EMMC_BSF=ardbeg_emmc.hush;
ITS_FILE=;
UIMAGE_LABEL="Linux-tegra12";
# BOARDID should be uncommented below when you dont have a EEPROM with correctly
# flashed Board Id and you want to pass a custom/known board id while flashing.
# This will override the EEPROM value if present
BOARDID="0x177 0x00 0x03";
I tried
This makes me wonder if the issue is on the root file system itself, and not the hardware. Was there anything special or different about the root file system? Do you still have the system.img.raw, and if so, is it loopback mountable, and what is the exact size of the image?