Hi,
sorry for the late discovery, but I just noticed that you said you want to flash the NVMe SSD on the title of this post, but you used mmcblk1p1 instead of nvme0n1p1 in the flashing command…
Can you help to confirm it it’s the root cause?
1 Like
Hello hello,
unfortunately I can not confirm that as the root-cause.
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" --showlogs --network usb0 jetson-orin-nano-devkit internal
…results as well in:
20230612_jetsonlog.log (246.2 KB)
Can we find out, if the NVMe is working together correctly with the DevKIT?
And a side-quest(ion): is there a tutorial available, on how to boot the Jetson from network / or how to flash it with a custom image over eth?
Hi,
what do you get from UART currently?
Aha - UART.log changed:
20230612_jet_ser.log (20.2 KB)
Hi,
are you sure you get this log with the correct flashing command?
(I mean, with nvme0n1p1)
Based on your flashing log, the device should at least be able to get into UEFI,
but it showed
Top caller module: SDMMC, error module: SDMMC, reason: 0x06, aux_info: 0x07
instead, which is weird.
So - I have tried it again - this time logging the flash-process on the side over UART.
The flash command (as seen in the log) has been:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" --showlogs --network usb0 jetson-orin-nano-devkit internal
…resulting in the log:
20230612_jet_flsh_2.log (246.3 KB)
From the perspective of the UART - flashing looked like this:
20230612_jet_ser_2_1.log (139.0 KB)
…what I find especially interesting about it are the last lines:
bash-5.0# [ 8.341491] tegra-xudc 3550000.xudc: EP 5 (type: intr, dir: in) enabled
[ 8.341707] tegra-xudc 3550000.xudc: EP 3 (type: bulk, dir: in) enabled
[ 8.341911] tegra-xudc 3550000.xudc: EP 2 (type: bulk, dir: out) enabled
[ 8.342194] IPv6: ADDRCONF(NETDEV_CHANGE): rndis0: link becomes ready
[ 8.342344] tegra-xudc 3550000.xudc: EP 7 (type: bulk, dir: in) enabled
[ 8.342586] tegra-xudc 3550000.xudc: EP 4 (type: bulk, dir: out) enabled
[ 8.386425] mmc1: SDHCI controller on 3400000.sdhci [3400000.sdhci] using ADMA 64-bit
[ 9.369277] blk_update_request: I/O error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0
[ 9.375633] blk_update_request: I/O error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 9.375930] Buffer I/O error on dev nvme0n1, logical block 0, async page read
[ 9.381934] blk_update_request: I/O error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 9.382218] Buffer I/O error on dev nvme0n1, logical block 0, async page read
[ 9.388254] blk_update_request: I/O error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 9.388536] Buffer I/O error on dev nvme0n1, logical block 0, async page read
[ 9.394547] blk_update_request: I/O error, dev nvme0n1, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0
[ 9.431679] blk_update_request: I/O error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 9.431978] Buffer I/O error on dev nvme0n1, logical block 0, async page read
[ 9.437990] blk_update_request: I/O error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 9.438267] Buffer I/O error on dev nvme0n1, logical block 0, async page read
[ 9.450937] blk_update_request: I/O error, dev nvme0n1, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0
[ 9.482903] Buffer I/O error on dev nvme0n1, logical block 0, async page read
[ 9.491245] Buffer I/O error on dev nvme0n1, logical block 0, async page read
…restarting the device and logging over UART results in the same log as before:
20230612_jet_ser_2_2.log (40.5 KB)
Based on that I would assume that testing another NVMe might make sense… - can you approve?
Hi, it sounds reasonable.
If swapping for a new NVMe SSD also does not work, try with a USB drive to make sure it’s not the issue of your host PC.
Update:
So this time I was trying to install the system on an external drive (USB-stick, instead of NVMe):
sudo ./apply_binaries.shsudo ./tools/l4t_flash_prerequisites.shsudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device sda1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" --showlogs --network usb0 jetson-orin-nano-devkit internal
It did not succeed again - but what was interesting was, that I got :
uart.log
20230620_jet_flash_ser.log (123.7 KB)
ending again in →
...
Waiting for target to boot-up...
Waiting for device to expose ssh ......RTNETLINK answers: File exists
RTNETLINK answers: File exists
Waiting for device to expose ssh ...Run command: flash on fc00:1:1:0::2
SSH ready
Flash failure
Cleaning up...
flash.log
20230620_jet_flash_usb_0.log (245.9 KB)
...
Add /dev/sda
[ 8.949821] rndis0: HOST MAC 9a:af:4a:e1:19:e7
[ 8.949953] rndis0: MAC 76:df:8c:45:34:8c
[ 8.951006] tegra-xudc 3550000.xudc: EP 0 (type: ctrl, dir: out) enabled
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
bash-5.0# [ 9.286862] tegra-xudc 3550000.xudc: EP 5 (type: intr, dir: in) enabled
[ 9.287082] tegra-xudc 3550000.xudc: EP 3 (type: bulk, dir: in) enabled
[ 9.287285] tegra-xudc 3550000.xudc: EP 2 (type: bulk, dir: out) enabled
[ 9.287559] IPv6: ADDRCONF(NETDEV_CHANGE): rndis0: link becomes ready
[ 9.287700] tegra-xudc 3550000.xudc: EP 7 (type: bulk, dir: in) enabled
[ 9.287960] tegra-xudc 3550000.xudc: EP 4 (type: bulk, dir: out) enabled
bash-5.0#
bash-5.0#
...
→ I would assume therefore, that the previous problems were not an issue of my NVMe.
→ I don’t know exactly what this shell in the end is about.
Could you remove "–network usb0 " in your command and try again?
Alright - this fails in a new way (…I would assume we are failing forward…):
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device sda1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" --showlogs jetson-orin-nano-devkit internal
results in:
uart.log
20230620_jet_flash_ser_1.log (93.6 KB)
...
8.738771] rndis0: HOST MAC b6:dd:e5:02:81:86
[ 8.738909] rndis0: MAC 7e:d2:3b:c4:7b:81
[ 8.739980] tegra-xudc 3550000.xudc: EP 0 (type: ctrl, dir: out) enabled
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
bash-5.0# [ 9.077713] tegra-xudc 3550000.xudc: EP 5 (type: intr, dir: in) enabled
[ 9.077935] tegra-xudc 3550000.xudc: EP 3 (type: bulk, dir: in) enabled
[ 9.078136] tegra-xudc 3550000.xudc: EP 2 (type: bulk, dir: out) enabled
[ 9.078409] IPv6: ADDRCONF(NETDEV_CHANGE): rndis0: link becomes ready
[ 9.078548] tegra-xudc 3550000.xudc: EP 7 (type: bulk, dir: in) enabled
[ 9.078797] tegra-xudc 3550000.xudc: EP 4 (type: bulk, dir: out) enabled
bash-5.0#
bash-5.0#
flash.log
20230620_jet_flash_usb_1.log (247.0 KB)
..
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for device to expose ssh ...Run command: if [ -f /qspi/l4t_flash_from_kernel.sh ]; then USER=root /qspi/l4t_flash_from_kernel.sh --no-reboot --qspi-only ; fi on root@fe80::1%usb0
blockdev: cannot open /dev/sde: No medium found
[ 0]: l4t_flash_from_kernel: Starting to create gpt for emmc
Active index file is /home/supergrobi/nvidia/Linux_for_Tegra/tools/kernel_flash/images/internal/flash.idx
Number of lines is 58
max_index=57
SSH ready
blockdev: cannot open /dev/mmcblk0boot0: No such file or directory
Flash index file is /qspi/internal/flash.idx
Number of lines is 58
max_index=57
[ 0]: l4t_flash_from_kernel: Starting to flash to qspi
QSPI storage size: 67108864 bytes.
[ 1]: l4t_flash_from_kernel: Successfully create gpt for emmc
Run command: partprobe /dev/mmcblk0 on root@fe80::1%usb0
Error: Could not stat device /dev/mmcblk0 - No such file or directory.
Error flashing non-qspi storage
Error flashing qspi
Further checking of things:
bash-5.0# ls
bin etc initrd_flash.cfg mnt qspi run sys usr
dev init lib proc root sbin tmp var
bash-5.0# ls /dev/
autofs capture-vi-channel20 media0 tty28
bsg capture-vi-channel21 mem tty29
bus capture-vi-channel22 mtd0 tty3
camchar-dbg capture-vi-channel23 mtd0ro tty30
camchar-echo capture-vi-channel24 net tty31
capture-isp-channel0 capture-vi-channel25 null tty32
capture-isp-channel1 capture-vi-channel26 nvhost-ctrl tty33
capture-isp-channel10 capture-vi-channel27 nvhost-ctrl-isp tty34
capture-isp-channel11 capture-vi-channel28 nvhost-ctrl-nvdec tty35
capture-isp-channel12 capture-vi-channel29 nvhost-isp tty36
capture-isp-channel13 capture-vi-channel3 nvhost-isp-thi tty37
capture-isp-channel14 capture-vi-channel30 nvhost-nvcsi tty38
capture-isp-channel15 capture-vi-channel31 nvhost-nvdec tty39
capture-isp-channel16 capture-vi-channel32 nvhost-nvjpg tty4
capture-isp-channel17 capture-vi-channel33 nvhost-nvjpg1 tty40
capture-isp-channel18 capture-vi-channel34 nvhost-ofa tty41
capture-isp-channel19 capture-vi-channel35 nvhost-tsec tty42
capture-isp-channel2 capture-vi-channel36 nvhost-vi0 tty43
capture-isp-channel20 capture-vi-channel37 nvhost-vi0-thi tty44
capture-isp-channel21 capture-vi-channel38 nvhost-vi1 tty45
capture-isp-channel22 capture-vi-channel39 nvhost-vi1-thi tty46
capture-isp-channel23 capture-vi-channel4 nvhost-vic tty47
capture-isp-channel24 capture-vi-channel40 nvme0 tty48
capture-isp-channel25 capture-vi-channel41 nvme0n1 tty49
capture-isp-channel26 capture-vi-channel42 nvsciipc tty5
capture-isp-channel27 capture-vi-channel43 port tty50
capture-isp-channel28 capture-vi-channel44 ppp tty51
capture-isp-channel29 capture-vi-channel45 ptmx tty52
capture-isp-channel3 capture-vi-channel46 pts tty53
capture-isp-channel30 capture-vi-channel47 ptyp0 tty54
capture-isp-channel31 capture-vi-channel48 ptyp1 tty55
capture-isp-channel32 capture-vi-channel49 ptyp2 tty56
capture-isp-channel33 capture-vi-channel5 ptyp3 tty57
capture-isp-channel34 capture-vi-channel50 ptyp4 tty58
capture-isp-channel35 capture-vi-channel51 ptyp5 tty59
capture-isp-channel36 capture-vi-channel52 ptyp6 tty6
capture-isp-channel37 capture-vi-channel53 ptyp7 tty60
capture-isp-channel38 capture-vi-channel54 ptyp8 tty61
capture-isp-channel39 capture-vi-channel55 ptyp9 tty62
capture-isp-channel4 capture-vi-channel56 ptypa tty63
capture-isp-channel40 capture-vi-channel57 ptypb tty7
capture-isp-channel41 capture-vi-channel58 ptypc tty8
capture-isp-channel42 capture-vi-channel59 ptypd tty9
capture-isp-channel43 capture-vi-channel6 ptype ttyAMA0
capture-isp-channel44 capture-vi-channel60 ptypf ttyS0
capture-isp-channel45 capture-vi-channel61 quadd ttyS1
capture-isp-channel46 capture-vi-channel62 quadd_auth ttyS2
capture-isp-channel47 capture-vi-channel63 random ttyS3
capture-isp-channel48 capture-vi-channel64 rfkill ttyTCU0
capture-isp-channel49 capture-vi-channel65 rtc0 ttyTHS0
capture-isp-channel5 capture-vi-channel66 rtc1 ttyTHS3
capture-isp-channel50 capture-vi-channel67 sda ttyTHS4
capture-isp-channel51 capture-vi-channel68 sda1 ttyp0
capture-isp-channel52 capture-vi-channel69 snd ttyp1
capture-isp-channel53 capture-vi-channel7 tee0 ttyp2
capture-isp-channel54 capture-vi-channel70 teepriv0 ttyp3
capture-isp-channel55 capture-vi-channel71 tegra-crypto ttyp4
capture-isp-channel56 capture-vi-channel8 tegra-nvvse-crypto ttyp5
capture-isp-channel57 capture-vi-channel9 tegra-soc-hwpm ttyp6
capture-isp-channel58 console tegra_camera_ctrl ttyp7
capture-isp-channel59 cpu_dma_latency tty ttyp8
capture-isp-channel6 dma_heap tty0 ttyp9
capture-isp-channel60 efi_capsule_loader tty1 ttypa
capture-isp-channel61 full tty10 ttypb
capture-isp-channel62 gpiochip0 tty11 ttypc
capture-isp-channel63 gpiochip1 tty12 ttypd
capture-isp-channel7 i2c-0 tty13 ttype
capture-isp-channel8 i2c-1 tty14 ttypf
capture-isp-channel9 i2c-10 tty15 uhid
capture-vi-channel0 i2c-2 tty16 uinput
capture-vi-channel1 i2c-3 tty17 urandom
capture-vi-channel10 i2c-4 tty18 vcs
capture-vi-channel11 i2c-5 tty19 vcs1
capture-vi-channel12 i2c-6 tty2 vcsa
capture-vi-channel13 i2c-7 tty20 vcsa1
capture-vi-channel14 i2c-8 tty21 vcsu
capture-vi-channel15 i2c-9 tty22 vcsu1
capture-vi-channel16 input tty23 watchdog
capture-vi-channel17 kmsg tty24 watchdog0
capture-vi-channel18 kvm tty25 zero
capture-vi-channel19 l3cache tty26
capture-vi-channel2 mapper tty27
bash-5.0# fdisk /dev/nvme0
Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.fdisk: cannot open /dev/nvme0: Illegal seek
bash-5.0# fdisk /dev/sda
Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.[ 3640.993664] sda: sda1
Command (m for help): p
Disk /dev/sda: 117.19 GiB, 125829120000 bytes, 245760000 sectors
Disk model: Flash Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 9BB4310B-F3FA-445A-BE18-ADD032FD4E36Device Start End Sectors Size Type
/dev/sda1 2048 67110911 67108864 32G Linux filesystem
→ Why is it blockdev’ing /dev/mmcblk0 when we explicitly tell it that --external-device sda1 ?
Thanks a lot.
Do you have any other jetson platforms that are using emmc to boot up (AGX Orin/AGX Xavier/TX2/Jetson Nano)?
I have some tests to try with such jetson and your host machine.
Jetson Orin nano/NX flash requires usb device mode connection between your host and jetson. I suspect the connection was not able to launched between your host and jetson.
Using other jetson platforms could be more easier to confirm if that is true.
I was flashing the Nano and the Xavier (both with Nano DevKit carrier boards) in the past without any problems (from this host-machine).
But as they are currently installed in some prototypes under test, I will not be able to access them in the near future.
→ Is it possible, to continue the installation manually from the initrd?
→ …, to perform a hardware-check, to figure out if everything works (NVMe obviously still seems weird)?
→ …, to check, if the configuration written is fine?
→ Can you explain what these parts of my log are about:
UART
Add /dev/sda
[ 8.773701] rndis0: HOST MAC 46:60:31:97:2e:48
[ 8.773835] rndis0: MAC 0a:35:fe:9b:c1:e0
[ 8.774915] tegra-xudc 3550000.xudc: EP 0 (type: ctrl, dir: out) enabled
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
USB
Run command: if [ -f /qspi/l4t_flash_from_kernel.sh ]; then USER=root /qspi/l4t_flash_from_kernel.sh --no-reboot --qspi-only ; fi on root@fe80::1%usb0
blockdev: cannot open /dev/sde: No medium found
[ 0]: l4t_flash_from_kernel: Starting to create gpt for emmc
Active index file is /home/supergrobi/nvidia/Linux_for_Tegra/tools/kernel_flash/images/internal/flash.idx
Number of lines is 58
max_index=57
SSH ready
blockdev: cannot open /dev/mmcblk0boot0: No such file or directory
Flash index file is /qspi/internal/flash.idx
Number of lines is 58
max_index=57
[ 0]: l4t_flash_from_kernel: Starting to flash to qspi
QSPI storage size: 67108864 bytes.
[ 0]: l4t_flash_from_kernel: Successfully create gpt for emmc
Run command: partprobe /dev/mmcblk0 on root@fe80::1%usb0
Error: Could not stat device /dev/mmcblk0 - No such file or directory.
Thank you.
Hi,
Bascially, initrd flash is
-
Flashing bootloader to QSPI on your jetson.
-
Boot into initrd. Use usb device mode connection to communicate with your host.
-
Host flashes the nvme drive.
I was flashing the Nano and the Xavier (both with Nano DevKit carrier boards) in the past without any problems (from this host-machine).
This comment does not provide any useful help here because I think you are using flash.sh to flash in the past. And flash.sh does not require usb device mode as initrd flash…
Ok - I understand.
- If we get to step 2, I assume that “Flashing bootloader to QSPI…” worked (is that right?)
- Testing the device-mode connection manually with
sudo picocom -b 115200 -p 1 -r -l /dev/ttyUSB0works fine. The privileges set for ttyUSB0 are:crw-rw---- 1 root sudo 188, 0 Jun 21 10:12 ttyUSB0- as we are running the script as root, there should not be a problem.
Is there anything more I can check on that? - Can I do that manually from initrd (or example boot from a net-image or manually mounting and booting from a pre-flashed sda1)?
Further:
To check on the thesis, that an issue with the USB-device-mode of my host is effecting the flash-procedure, I have tried now to manually flash the USB, following the instructions from: Flashing Support — Jetson Linux<br/>Developer Guide 34.1 documentation which is making use of sudo ./flash.sh jetson-orin-nano-devkit sda1.
USB
20230622_jet_flash_0.log (71.5 KB)
...
[ 9.9163 ] Applet/MB2 is not running on device.
[ 2055.7415 ] Error: failed to get storage info
[ 2056.7533 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 3071.5511 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 4088.3604 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 5103.1643 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 6119.9771 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 7134.7812 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 8151.5907 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 9166.3979 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 10183.2070 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 11198.0144 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 12214.8247 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 13229.6302 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 14246.4354 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 15261.2469 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 16278.0549 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 17292.8618 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 18309.6697 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 19324.4784 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 20341.2866 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 21356.0948 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 22372.9021 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 23387.7099 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 24404.5196 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 25419.3273 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 26436.1367 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 27450.9410 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 28467.7477 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 29482.5565 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 30499.3685 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 31514.1749 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 32530.9814 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 33545.7912 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 34562.5987 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 35577.4087 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 36594.2163 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 37609.0211 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 38625.8282 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 39640.6387 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 40657.4489 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 41672.2536 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 42689.0604 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 43703.8658 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 44720.6803 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 45735.4860 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 46752.2914 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 47767.1029 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 48783.9083 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 49798.7191 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 50815.5286 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 51830.3296 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 52847.1425 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 53861.9509 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 54878.7596 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 55893.5651 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 56910.3744 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 57925.1820 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 58941.9906 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 59956.7996 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 60973.6081 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 61988.4151 ] tegrarcm_v2 --chip 0x23 0 --ismb2
Error: None of the bootloaders are running on device. Check the UART log.
UART
20230622_jet_uart_0.log (21.7 KB)
...
E> Error in command_complete 18001 int_status
E> Sending CMD_SD_SEND_IF_COND failed
E> Error opening sdcard-0
E> Failed to initialize device 6-0
C> Storage init failed
C> Task 0x0 failed (err: 0x39390706)
E> Top caller module: SDMMC, error module: SDMMC, reason: 0x06, aux_info: 0x07
I> Busy Spin
→ checking the UART-log → why does it want to open the sdcard-0? Noone told it to do so?
→ what else could be wrong with the host?
One needs to have an SD-card plugged into the DevKit module, no matter what one wants to flash (NVMe, USB, etc.), no?
Hi,
This is a long story to explain. I had a old post on jetson nano forum which explained a little.
Basically, you could only use the commands with initrd flash command to flash your jetson orin nano/nx. It is same command you are using in the beginning.
Could you flash your “xavier nx” with flash.sh first, boot it up and see if you see the xavier nx device in your lsusb command on host PC? If you can see it, please ping it using the usb interface IP.
Any update on this
Hello bberry196,
one of the problems of my setup was, that ethernet through USB did not work - so one (unsatisfying) workaround was to just flash the bootloader and then boot and install from an external device.
The other one (which still does not work) is:
- Jet.Or.Nan.Dev. connected to host through:
** USB->USBc: for QSPI-firmware-flash
** serial: for debugging
** eth0: for NVMe-flash dnsmasqas a DHCP-server on host- flash accroding to
Linux_for_Tegra/tools/kernel_flash/README_initrd_flash.txt
with:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
--showlogs \
--erase-all \
--external-device nvme0n1p1 \
-c tools/kernel_flash/flash_l4t_external.xml \
-p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml --no-systemimg" \
--network eth0:$cli_ip/$subnet:$hostip \
--external-only \
jetson-orin-nano-devkit external
cd ./bootloader \
sudo bash ./flashcmd.txt
On host side everything seems to work fine, and the command finishes with:
…
[ 0.3211 ] tegrarcm_v2 --chip 0x23 0 --pollbl --download bct_mem mem_rcm_sigheader.bct.encrypt --download blob blob.bin
[ 0.3218 ] BL: version 0.32.0.0-t234-54845784-57325615 last_boot_error: 0
[ 0.3449 ] Sending bct_mem
[ 0.3756 ] Sending blob
[ 3.3438 ] RCM-boot started
On side of the Jetson we get through the Bootloader loading Linux - but then are stuck with:
[ 19.708928] ERROR: mmcblk0p1 not found
Full log here:
20230707_jet_log_lin.log (52.7 KB)
Thats where we are rn.
regards / servus