Jetson Orin Nano Developer board and installed a 256G SSD on it. I already used JetPack 6.0 on a X86 host machine to flash these boards with Ubuntu 22.04.
I built a new Bootloader, moved to ‘bootloader’ directory and tried to flash on B slot since my current slot was A. I used this command:
sudo ./flash.sh -k B_cpu-bootloader -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit nvme0n1p1
But, the process finished with some error messages:
Error: Return value 4
Command tegradevflash_v2 --write B_cpu-bootloader uefi_jetson_with_dtb_sigheader.bin.encrypt
Failed to flash/read generic.
Did I flash successfully? If yes, why these error messages?
More information, I just tested. I manually switched the active boot slot to B. But, it failed to boot.
Eventually, it automatically switched back to slot A and booted up. I used ‘sudo nvbootctl dump-slots-info’ to read the boot slot information. These were outputs:
Current version: 0.0.1
Capsule update status: 0
Current bootloader slot: A
Active bootloader slot: A
num_slots: 2
slot: 0, status: normal
slot: 1, status: unbootable
‘slot 1’ became ‘unbootable’. It used to be 'normal before I tried to flash it.
I don’t want to flash to Slot A anymore since that is only slot that I can boot from now.
The ‘uefi_jetson.bin’ size is: 3801088 (built without docker). The only changed that I made was to replace three Nvidia boot up Logos (those 3 .bmp files) with mine. The .bmp file size is small, about 800 k.
The problem was the nvidia LOGO files (nvidiagray480.bmp, nvidiagray720.bmp and nvidiagray1080.bmp,). I used the original logo files and the ‘uefi_jetson_RELEASE.bin’ size was about 3.3M in size. I could update the bootloader on any slot successfully and the system would boot up correctly from the just updated slot.
However, if I replaced any of the .bmp file, say: nvidiagray480.bmp, with another 640x480 resolution bmp file (downloaded from internet, same size as the original one, 921.7k) and did not change anything else. The ‘uefi_jetson_RELEASE.bin’ size became about 3.9M in size even if the size of ‘nvidiagray480.bmp’ is the same as the original one.
Apparently, 3.9M in size was too big for UEFI partition so the flash would fail.
How could it possible? I just used a different .bmp file (cannot attache here due to your website limitation) with pretty much the same size. Why was a 600 k in size difference’s ‘uefi_jetson_RELEASE.bin’ produced by compiler?
Does Nvidia have some special requirement for the ‘.bmp’ LOGO file?
BTW, you said ‘please move to rel-36.3 This 36.2 is just a developer preview and you should not use it anymore.’,
what package did you refer to?
Hi,
I tried a different ‘.bmp’ picture (very similar size as the original nvidiagray480.bmp) and got the same problem.
I also tried a different approach. I updated the first file name in Platform/NVIDIA/NVIDIA.fvmain.fdf.inc, let it point to the new ‘.bmp’ file. I had the same problem. Final ‘uefi_jetson_.bin’ file is too big in size.
Once I change back (let the file point to the original nvidiagray480.bmp file), the final '.bin’ file’s size is correct.
It really did NOT make any sense. Do you have any special requirement for the ‘.bmp’ LOGO files?
’ Please verify with [R36.3] instead of [R36.2].’
How do I verify? I already updated to the latest SDK manager (2.1.0.11682) with JetPack (rev. 2).
If mine is not correct, do you have any instructions how to upgrade to 36.3?
Please see the attached bmp file (downloaded from the internet), compressed in zip file format.
The original file (nvidiagray480.bmp) is 921,654 bytes and the bmp file attached here is 921,656 bytes.
My bmp file is only 2-byte larger the default one. But, don’t know why size for the final file, uefi_jetson.bin’, is about 600 K larger.
Current ‘nvidia-l4t-apt-source.list’ file outputs:
seattle@SeattleOrin:~/nvidia/nvidia_sdk/JetPack_6.0_DP_Linux_DP_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/rootfs$ more etc/apt/sources.list.d/nvidia-l4t-apt-source.list
SPDX-FileCopyrightText: Copyright (c) 2019-2021 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
Hi,
More information, here are the outputs when I ran those three commands (tried to upgrade from r36.2 to 36.3).
Note: I already changed the version to r36.3 in both lines on the file etc/apt/sources.list.d/nvidia-l4t-apt-source.list.
seattle@SeattleOrin:~$ sudo apt update
Get:1 file:/var/cuda-repo-cross-aarch64-ubuntu2204-12-2-local InRelease [1,572 B]
Get:1 file:/var/cuda-repo-cross-aarch64-ubuntu2204-12-2-local InRelease [1,572 B]
Get:2 file:/var/cuda-repo-ubuntu2204-12-2-local InRelease [1,572 B]
Get:2 file:/var/cuda-repo-ubuntu2204-12-2-local InRelease [1,572 B]
Hit:3 Index of /ubuntu jammy InRelease
Hit:4 Index of /ubuntu jammy-security InRelease
Hit:5 Index of /ubuntu jammy-updates InRelease
Hit:6 Index of /ubuntu jammy-backports InRelease
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
3 packages can be upgraded. Run ‘apt list --upgradable’ to see them.
seattle@SeattleOrin:~$ sudo apt dist-upgrade
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
Calculating upgrade… Done
The following packages have been kept back:
python3-update-manager update-manager update-manager-core
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
seattle@SeattleOrin:~$ sudo apt install --fix-broken -o Dpkg::Options::=“–force-overwrite”
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
seattle@SeattleOrin:~$
Apparently, no package was downloaded back. This was why nothing was updated after rebooting.
I just use ExifTool to compare you BMP logo file and found the difference between ours.
Your 640x480.bmp
ExifTool Version Number : 10.80
File Name : 640x480.bmp
Directory : .
File Size : 900 kB
File Modification Date/Time : 2024:07:08 16:35:49+08:00
File Access Date/Time : 2024:07:08 16:35:58+08:00
File Inode Change Date/Time : 2024:07:08 16:35:49+08:00
File Permissions : rw-rw-r--
File Type : BMP
File Type Extension : bmp
MIME Type : image/bmp
BMP Version : Windows V3
Image Width : 640
Image Height : 480
Planes : 1
Bit Depth : 24
Compression : None
Image Length : 0
Pixels Per Meter X : 11808
Pixels Per Meter Y : 11808
Num Colors : Use BitDepth
Num Important Colors : All
Image Size : 640x480
Megapixels : 0.307
Our nvidiagray480.bmp:
ExifTool Version Number : 10.80
File Name : nvidiagray480.bmp
Directory : .
File Size : 900 kB
File Modification Date/Time : 2024:07:03 16:58:34+08:00
File Access Date/Time : 2024:07:08 16:50:54+08:00
File Inode Change Date/Time : 2024:07:08 16:46:17+08:00
File Permissions : rw-r--r--
File Type : BMP
File Type Extension : bmp
MIME Type : image/bmp
BMP Version : Windows V3
Image Width : 640
Image Height : 480
Planes : 1
Bit Depth : 24
Compression : None
Image Length : 921602
Pixels Per Meter X : 2834
Pixels Per Meter Y : 2834
Num Colors : Use BitDepth
Num Important Colors : All
Image Size : 640x480
Megapixels : 0.307
It seems the Image Length, Pixels Per Meter X, Pixels Per Meter Y are different.
(i.e. the resolution is higher in your logo file)
Please try using another BMP image to verify.
The SDK on my host PC is 2.1.0.11682 which is up-to-date already. SDK would NOT update anything. In other words, SDK would not update Jetpack R36.2 (DP) to R36.3 (GA) for me.
For manual update to 36.3, which BSP package do I need to install? Do you have any instructions?
Hi,
I already updated my system to r36.3.
I tried a few different 640x480 BMP images. But, after made the build, none of them could give me the correct binary image size. I attached one of bmp files here. The ‘uefi_Jetson_RELEASE.bin’ file (built with docker using the attached bmp file) was over 4 M and it is too big for your UEFI. If using your default ‘.bmp’ file, the binary files size will only be around 3.2 M.
I also used ExifTool to look at the details of the attached file:
ExifTool Version Number : 12.87
File Name : 640x480-1.bmp
Directory : …/Users/stevenc/Pictures
File Size : 922 kB
Zone Identifier : Exists
File Modification Date/Time : 2024:07:10 10:53:16-05:00
File Access Date/Time : 2024:07:10 10:53:58-05:00
File Creation Date/Time : 2024:07:10 10:53:15-05:00
File Permissions : -rw-rw-rw-
File Type : BMP
File Type Extension : bmp
MIME Type : image/bmp
BMP Version : Windows V5
Image Width : 640
Image Height : 480
Planes : 1
Bit Depth : 24
Compression : None
Image Length : 921600
Pixels Per Meter X : 0
Pixels Per Meter Y : 0
Num Colors : Use BitDepth
Num Important Colors : All
Red Mask : 0x00ff0000
Green Mask : 0x0000ff00
Blue Mask : 0x000000ff
Alpha Mask : 0xff000000
Color Space : sRGB
Rendering Intent : Picture (LCS_GM_IMAGES)
Image Size : 640x480
Megapixels : 0.307
in this BMP file, the file size is close, and Image Length is very close too.
Why did the ‘.bin’ file is so different? Do you have any special requirement for the ‘.bmp’ logo files?
Hi,
Thanks for the reply.
Attached are Build and Update log files. If you need any other log files, please let me know which ones? The generated UEFI binary files are 4 M and they are too big. See ‘ls -l’ command outputs:
I previously attached two 640x480 BMP image files and you can use either of them.
For 1280x720 and 1920 x1080 BMP image files, I did not change them. In other words, I still used the default files from Nvidia. So, I did not attach anything here.
Here are the ‘git’ status outputs. you can see I only changed 640x400 LOGO image and did NOT change anything else.
seattle@Ubuntu2204-1:~/nvidia-uefi-r36.3.0/edk2-nvidia$ git status -uno
HEAD detached at r36.3.0
Changes not staged for commit:
(use “git add …” to update what will be committed)
(use “git restore …” to discard changes in working directory)
modified: Silicon/NVIDIA/Assets/nvidiagray480.bmp
no changes added to commit (use “git add” and/or “git commit -a”)