topic still relevant, up
Do you mean that this custom carrier board can use jetson-orin-nano-devkit as board config to be flashed?
Before you perform OTA update, I would suggest you confirming that this board can be flashed and boot up with jetson-orin-nano-devkit as board config in both JP5.1.3 and JP6.1.
L4TLauncher: Attempting Direct Boot
EFI stub: Booting Linux Kernel...
EFI stub: ERROR: Invalid header detected on UEFI supplied FDT, ignoring ...
EFI stub: Generating empty DTB
From the log you shared, it seems the DTB cannot be found.
Jetson UEFI firmware (version 202210.4-a5ac12d7-dirty built on 2024-02-27T13:00:
I would also like to know if you have replaced bootloader with custom UEFI binary.
Do you mean that this custom carrier board can use
jetson-orin-nano-devkitas board config to be flashed?
About flashed I am not sure, I used special config from them recomputer-orin-j401, but custom BSP maintainer said, they tested OTA 5.1.3 → 6.0 via jetson-orin-nano-devkit and it did worked, I have tho 6.1 but minor patch should not be a problem?
I would suggest you confirming that this board can be flashed and boot up with
jetson-orin-nano-devkitas board config in both JP5.1.3 and JP6.1.
For J5.1.3 was used this config p3509-a02+p3767-0000 from official nvidia bsp, custom board supported it ( maybe even support now )
For J6 was created this config recomputer-orin-j401
So, I am not sure if my board support default devkit config, but here their answer about it
From the log you shared, it seems the DTB cannot be found.
How I can find which one is missing?
I would also like to know if you have replaced bootloader with custom UEFI binary.
Yes, was created modified UEFI with removed network boot options, it can be overwritten by golden image now ( if its possible ) as in new UEFI there is no such problem anymore
You should use the exact same board config for both flash and OTA package.
(i.e. if you use jetson-orin-nano-devkit.conf to flash the board, you should use the same board config to generate OTA package)
So, it is not the expected usage to me since OTA tool will check the board spec from the board and the one specified during OTA update.
I think golden image only including the data from rootfs rather than bootloader(UEFI).
Yeah, but if board it self are support it ( from Seeed words ) we can ignore this check, right? How I understood they just make an human readable alias for new jetpack with additional dtb files
I think golden image only including the data from rootfs rather than bootloader(UEFI).
I believe OTA bring new bootloader by default, as this options are available for OTA package
As a separate solution, I have ready MFI package with J6, is it possible to use with OTA? so it just overwrite everything on device by MFI package, but remotely?
As my understanding, there’s a board spec(ota_board_specs.conf) in ota tool and it will check if the board(to perform OTA update) is valid(in the list) before OTA update process.
I’m not clear about why you can ignore this check, maybe there’re some customizations have been done?
If so, you can ask them for details since we’ve not verified them.
Correct. OTA package will include all contents including bootloader, kernel, rootfs.
What I mean is that bootloader is not included in golden image. (system.img.raw)
MFI package is only available for using USB-C cable to flash.
For OTA, please refer to Image_based_OTA_Examples.txt.
OTA tools are official, I modified line in OTA scripts to ignore if config name does not match, its probably not possible to make them matchable, as Seeed says its fine
I am a bit lost at this point, trying to check DTB problem
J5.1.3:
/boot/dtb/kernel_tegra234-p3767-0003-p3509-a02.dtb
cat /boot/extlinux/extlinux.conf
TIMEOUT 30
DEFAULT primary
MENU TITLE L4T boot options
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
FDT /boot/dtb/kernel_tegra234-p3767-0003-p3509-a02.dtb
INITRD /boot/initrd
APPEND ${cbootargs} root=PARTUUID=d3580ebd-6ca0-4331-b02e-f54ba38ef076 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 nospectre_bhb
J6 are extlinux config not even pointing to FDT file
/boot/dtb/kernel_tegra234-j401-p3768-0000+p3767-0003-recomputer.dtb
$ cat /boot/extlinux/extlinux.conf
TIMEOUT 30
DEFAULT primary
MENU TITLE L4T boot options
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} root=PARTUUID=29e82608-5415-4a34-b0cc-96a3d0151c1b rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 nospectre_bhb video=efifb:off console=tty0
Please refer to DTB Support for the DTB loading in JP6.
DTB is packaged with UEFI during flash and it would be loaded if FDT is not specified.
As a result, you can also add FDT entry back in extlinux.conf to assign the DTB file.
I am a bit far from such deeper knowledge, but trying to understand:
in J6 DTB can be packaged in UEFI, but UEFI it self remain old, during boot: Jetson UEFI firmware (version 202210.4-a5ac12d7-dirty built on 2024-02-27T13:00: 14+00:00) means during OTA, UEFI update actually failed, and then when system try to boot, think UEFI are new but there is no DTB packaged and it crashed? if my conclusions are true:
- I have to search why UEFI update failed?
- or way to fix missing DTB by manually set it in extlinux.conf?
You can check the full serial console log to know if UEFI has been updated.
There should be a progress bar in UEFI during update.
Or you can try to perform capsule update only to update bootloader.
I’m not sure if adding FDT entry in extlinux.conf could fix your OTA update issue.
Back to my previous suggestion, have you tried using jetson-orin-nano-devkit as board config to flash and boot up successfully with both JP5.1.3 and JP6.1?
Back to my previous suggestion, have you tried using
jetson-orin-nano-devkitas board config to flash and boot up successfully with both JP5.1.3 and JP6.1?
Not yet, I will try to test it and comeback with update, thank you for help
HI Kevin,
Currently Seeed assisting me to make this update happen, remain last problem: during OTA UEFI are not updating and just skipping
From my understanding thats because board name are not matching, as when I tried to make capsule update in J6.1 for remove network stack it didnt worked until I changed scripts for compiling BUP and change board name to mine: recomputer-orin-j401
I tried to replicate the same logic for OTA, but it still dont start and we have:
- rootfs updated
- UEFI remain old
and device just bricked
Could you help me how to disable UEFI verification check during update? Here we have a discussion
up, topic still relevant
up, topic still relevant
Sorry for the late reply since I had few holidays before.
Have you tried to use p3509-a02+p3767-0000 as board config name instead of recomputer-orin-j401?
(i.e. just rename your board config but keep all your custom configurations )
$ mv recomputer-orin-j401.conf p3509-a02+p3767-0000.conf
HI Kevin,
No problem, thank you for your time
Have you tried to use
p3509-a02+p3767-0000as board config name instead ofrecomputer-orin-j401?
Yes, but in a bit different way, to make symlink p3509-a02+p3767-0000 -> jetson-orin-nano-devkit as a lot of verification inside OTA scripts for check compatibility. ( recomputer-orin-j401 -> jetson-orin-nano-devkit was checked too )
As scripts dont know anything about p3509-a02+p3767-0000 it dont start at all, after OTA package created with faked jetson-orin-nano-devkit I disable boardname verification at trigger script, rootfs are changed, but UEFI still dont
I compiled separate UEFI for J6.1 for remove network boot, tried to tamper OTA package with binary which will for sure work, but it just got skipped. Thats why I am looking a way to bypass verification just like for rootfs, the whole problem in config name
Do you mean that you’ve tried to rename recomputer-orin-j401.conf to jetson-orin-nano-devkit.conf with the follownig command but the bootloader(UEFI) still not be triggered for update?
$ mv recomputer-orin-j401.conf jetson-orin-nano-devkit.conf
If so, have you tried with capsule update only?
No, 2 attempts:
- rename
recomputer-orin-j401.conf→jetson-orin-nano-devkit - rename
p3509-a02+p3767-0000.conf→jetson-orin-nano-devkit
In order to successfully create OTA package for special config like recomputer-orin-j401.conf or p3509-a02+p3767-0000.conf need to make a lot of changed in OTA scripts for pass verification and missing spec files, even they are compatible ( with slightly changed dtb files which renaming are solving I hope )
Thats why I just rename to jetson-orin-nano-devkit in order to make good OTA package even with generic board name
Yes, but was able to make it work only with changed BUP generation scripts for add custom spec files and insert my board name inside, I tried to do it the same for generate OTA packages, but it didnt worked
If you’ve renamed your boar config(recomputer-orin-j401.conf) to jetson-orin-nano-devkit.conf, then there should be no issue for OTA script to identify your custom board conifg.
What you’ve done there?
Actually, capsule update is included in image-based OTA update. They should do the similar things and flow to update bootloader.
But my custom board have different board name, they dont match and script just stop working after that
tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh
# Generate BUP
function generate_BUP()
{
local suffix="${1}"
local bup_generator="${LINUX_BASE_DIR}"/l4t_generate_soc_bup.sh
local chipid=
case ${CHIPID} in
0x23) chipid=t23x; ;;
*)
echo "Error: un-supported CHIPID(${CHIPID})"
exit 1
;;
esac;
local board_name="${TARGET_BOARD}"
local payload_dir="${BOOTLOADER_DIR}"/payloads_"${chipid}"
local cmd=
# Construct the board spec entry used to generate BUP
local __board_spec_file=tools/ota_tools/version_upgrade/ota_board_specs.conf
local __board_spec_entry="jetson_orin_nano_devkit_ota_emmc_r35_r36_spec"
#construct_board_spec_entry "${suffix}" "${__board_spec_entry}" "${__board_spec_file}"
Commented construct_board_spec_entry, it will create some default spec only for jetson-orin-nano-devkit, set __board_spec_file and __board_spec_entry to use my specs where recomputer-orin-j401 exists
I dont fully understand for what it will create temporary spec in /tmp folder for bup, when special file for that already exists ota_board_specs.conf