We have enabled A/B redundancy on TX2 and when flashing, this comes up OK. After OTA It boots into the alternate partition - however, I find that although the root filesystem is successfully updated, the kernel which is run has not been updated.
From what I can see in the OTA upgrade routines the kernel should be updated here in ota_update_without_layout_change.sh,
# When ROOTFS A/B is enabled, the images update on kernel/kernel-dtb partitions
# are tied to rootfs update. So we need to run "nv_bootloader_payload_updater"
# with individual partition update option to update specific partition.
#
# When ROOTFS A/B is disabled, the images update on kernel/kernel-dtb partitions
# are done along with bootloader update (in function update_bootloader_with_UE).
#
# Update kernel and kernel-dtb partition
local _nv_bootloader_payload_updater=
_nv_bootloader_payload_updater="$(which nv_bootloader_payload_updater)"
cp -f "${kernel_only_image}" "/opt/ota_package/bl_update_payload"
if ! eval "${_nv_bootloader_payload_updater}" --part "kernel${suffix}"; then
ota_log "Failed to run \"${_nv_bootloader_payload_updater} --part kernel${suffix}\""
return 1
fI
if ! eval "${_nv_bootloader_payload_updater}" --part "kernel-dtb${suffix}"; then
ota_log "Failed to run \"${_nv_bootloader_payload_updater} --part kernel-dtb${suffix}\""
return 1
fi
this code appears to be running, and updating the kernel/kernel-dtb slots - however when u-boot starts, it does not look at the kernel/kernel-dtb lots, rather it looks at a filesystem parition 1or 2 which contains extlinux.conf
mmc0(part 0) is current device
Scanning mmc 0:2...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
853 bytes read in 21 ms (39.1 KiB/s)
1: primary kernel
Retrieving file: /boot/initrd
7238963 bytes read in 186 ms (37.1 MiB/s)
Retrieving file: /boot/Image
34695176 bytes read in 833 ms (39.7 MiB/s)
append: console=ttyS0,115200 root=PARTUUID=8c188c64-e551-4893-9d2c-e4f34a7c3e9d rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 video=tegrafb earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x1772e0000 gpt root
fs.slot_suffix=_b usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix=_b boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x175840000 sdhci_tegra.en_boot_part_access=1 quiet root=/dev/sda2 rw rootwait rootfstype=ex
t4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2
## Flattened Device Tree blob at 80000000
Booting using the fdt blob at 0x80000000
These are located at
gdisk -l /dev/mmcblk0
...
...
Number Start (sector) End (sector) Size Code Name
1 4104 14684167 7.0 GiB 0700 APP
2 14684168 29364231 7.0 GiB 0700 APP_b
But this isnât the partition which is updated with the OTA , which seems to update.
itâs bootloader functionality for loading kernel and kernel-dtb via file system if thereâs LINUX and FDT entry specified in the extlinux.conf.
since your root filesystem is successfully updated, it should read updated binary files.
do you see any failure by moving from r32.7.2 to r32.7.3?
I donât think we have any failure from moving from r32.7.2 to r32.7.3.
So my current understanding is that uboot will load and boot the kernel and the initrd from the nvme0 - this is based on the u-boot environment variable boot_targets.
Currently, we have
boot_targets=mmc1 mmc0 usb0 nvme0 pxe dhcp
This seems to mean that u-boot will first search the EMMC for a bootable partition, and then it will look for extlinux.conf from there. Actually - it does find one there, and it goes ahead and boots and loads it - however, this is not actually what we want - as we are doing a full image upgrade, we want it to look on the NVME drive for a bootable partition, and get it from there.
We are able to force this by setting âboot_targets=nvme0â, and then it will look there first instead of the EMMC.
I am still not clear about the device tree - I canât see any code in the u-boot environment which is loading a device tree from the filesystem - but it does appear to be being loaded from somewhere.
We donât have any FDT entry in our extlinux.conf file, but I do see
Device 0: Vendor: 0x15b7 Rev: 731030WD Prod: 223337476304
Type: Hard Disk
Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
... is now current device
Scanning nvme 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
889 bytes read in 16 ms (53.7 KiB/s)
1: primary kernel
Retrieving file: /boot/initrd
7238963 bytes read in 38 ms (181.7 MiB/s)
Retrieving file: /boot/Image
34695176 bytes read in 150 ms (220.6 MiB/s)
append: console=ttyS0,115200 root=PARTUUID=d1bcd5d3-2325-49de-a3f1-c80af9d2e422 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 video=tegrafb earlycon=uart8250,mmio32,0x3100000 nvdum
per_reserved=0x1772e0000 gpt rootfs.slot_suffix= usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x175840000 sdhci_tegra.en_boo
t_part_access=1 quiet root=PARTUUID=d1bcd5d3-2325-49de-a3f1-c80af9d2e422 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2
## Flattened Device Tree blob at 80000000
Booting using the fdt blob at 0x80000000
ERROR: reserving fdt memory region failed (addr=0 size=0)
ERROR: reserving fdt memory region failed (addr=0 size=0)
ERROR: reserving fdt memory region failed (addr=0 size=0)
Using Device Tree in place at 0000000080000000, end 0000000080034c96
copying carveout for /host1x@13e00000/display-hub@15200000/display@15200000...
copying carveout for /host1x@13e00000/display-hub@15200000/display@15210000...
copying carveout for /host1x@13e00000/display-hub@15200000/display@15220000...
Starting kernel ...
Where is the âFlattened Device Tree Blob at 80000000â file loaded from ?
Thanks.
itâs loading device tree binary via kernel-dtb partition.
and⊠you may ignore those errors since theyâre harmless.
I canât actually see where that the device tree is being loaded from the kernel-dtb partition in U-boot - Can you please indicate where this is being loaded ?
I can see that the kernel, and initrd are being loaded by u-boot, but I canât see anything which does this for the device tree.
Below is the u-boot environment
U-Boot 2020.04-g4335beb (Nov 22 2022 - 09:21:33 -0800)
SoC: tegra186
Model: NVIDIA P3636-0001
Board: NVIDIA P3636-0001
DRAM: 3.8 GiB
MMC: sdhci@3400000: 1, sdhci@3460000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net:
Warning: ethernet@2490000 using MAC address from ROM
eth0: ethernet@2490000
Hit any key to stop autoboot: 0
Tegra186 (P3636-0001) # print
arch=arm
baudrate=115200
board=p3636-0001
board_name=p3636-0001
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_dcache_off=dcache off
boot_efi_binary=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr ${fdtcontroladdr};fi;load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_add
r_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
boot_net_usb_start=usb start
boot_pci_enum=pci enum
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_syslinux_conf=extlinux/extlinux.conf
boot_targets=mmc1 mmc0 usb0 nvme0 pxe dhcp
bootcmd=run distro_bootcmd
bootcmd_dhcp=run boot_net_usb_start; run boot_pci_enum; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:00
3000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_
arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_mmc0=devnum=0; run mmc_boot
bootcmd_mmc1=devnum=1; run mmc_boot
bootcmd_nvme0=devnum=0; run nvme_boot
bootcmd_pxe=run boot_net_usb_start; run boot_pci_enum; dhcp; if pxe get; then pxe boot; fi
bootcmd_usb0=devnum=0; run usb_boot
bootdelay=2
calculated_vars=kernel_addr_r fdt_addr_r scriptaddr pxefile_addr_r ramdisk_addr_r
cbootargs=console=ttyS0,115200 root=PARTUUID=8c188c64-e551-4893-9d2c-e4f34a7c3e9d rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 video=tegrafb earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x1772e0000 gpt ro
otfs.slot_suffix=_b usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix=_b boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x175840000 sdhci_tegra.en_boot_part_access=1
check_rootfs_ab=for args in ${cbootargs}; do rootfs_b=rootfs.slot_suffix=_b; if test ${args} = ${rootfs_b}; then setenv devplist 2; fi; done
cpu=armv8
distro_bootcmd=setenv nvme_need_init; for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
ethaddr=48:b0:2d:3b:40:f3
fdt_addr=80000000
fdt_addr_r=88400000
fdt_addr_r_align=00200000
fdt_addr_r_offset=00000000
fdt_addr_r_size=00200000
fdt_copy_node_paths=/chosen/plugin-manager:/chosen/reset:/memory@80000000
fdt_copy_prop_paths=/bpmp/carveout-start:/bpmp/carveout-size:/chosen/nvidia,bluetooth-mac:/chosen/nvidia,ether-mac:/chosen/nvidia,wifi-mac:/chosen/ecid:/chosen/linux,initrd-start:/chosen/linux,initrd-end:/reserved-memory/fb0_carveout/reg:/reserved-memory/fb1_carveout/reg
:/reserved-memory/fb2_carveout/reg:/reserved-memory/ramoops_carveout/alignment:/reserved-memory/ramoops_carveout/alloc-ranges:/reserved-memory/ramoops_carveout/size:/reserved-memory/vpr-carveout/alignment:/reserved-memory/vpr-carveout/alloc-ranges:/reserved-memory/vpr-ca
rveout/size:/serial-number:/trusty/status
fdt_copy_src_addr=80000000
fdt_high=ffffffffffffffff
fdtcontroladdr=ff7f9058
fdtoverlay_addr_r=0x90200000
initrd_high=ffffffffffffffff
kernel_addr_r=80280000
kernel_addr_r_aliases=loadaddr
kernel_addr_r_align=00200000
kernel_addr_r_offset=00080000
kernel_addr_r_size=08000000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
loadaddr=80280000
mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
nvme_boot=run boot_pci_enum; run boot_dcache_off; run nvme_init; if nvme dev ${devnum}; then devtype=nvme; run scan_dev_for_boot_part; fi
nvme_init=if ${nvme_need_init}; then setenv nvme_need_init false; nvme scan; fi
pxefile_addr_r=88800000
pxefile_addr_r_align=00200000
pxefile_addr_r_offset=00000000
pxefile_addr_r_size=00200000
ramdisk_addr_r=88a00000
ramdisk_addr_r_align=00200000
ramdisk_addr_r_offset=00000000
ramdisk_addr_r_size=02000000
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; run check_rootfs_ab; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; d
one; setenv devplist
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then
echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=88600000
scriptaddr_align=00200000
scriptaddr_offset=00000000
scriptaddr_size=00200000
soc=tegra186
stderr=serial
stdin=serial
stdout=serial
usb_boot=run boot_pci_enum; usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi
vendor=nvidia
Environment size: 5978/8188 bytes
Tegra186 (P3636-0001) #
device tree binary is loaded via kernel-dtb partition as long as thereâs no Retrieving file.. messages from bootloader messages.
you may see-also Topic 180197 for the explanation for u-boot loading DTB.
To be more accurate, U-Boot will load a DTB blob if (and only if) itâs declared in your extlinux.conf file via the FDT= line. This isnât done by default, so U-Boot uses the DTB inherited from the lower-level bootloader (nvtboot/MB2/TegraBoot), which s/b passed in the fdt_addr variable. U-Boot will make some minor adjustments to properties & nodes in that DTB, then pass it on to the kernel.
If you have a kernel DTB that you want loaded with our kernel, place a FDT=/boot/dtb/ line in the /boot/extlinux/extlinux.conf file on your boot media (eMMC, or SD-card, or USB, etc.) and you should see it loaded by U-Boot in the boot spew, i.e. âRetrieving file: /boot/dtb/â.