Specifying the size rootfs of a partition (-S) breaks DT upgrade

Hello.

During investigation of previous issue (Jetson TX2 Ethernet module doesn't work after update to L4T 32.6.1 - #10 by mr.ivanov) I found out that root cause of errors in eqos module was nor deployment tool or upgrade process but specifying -S parameter to the L4T flash.sh script.

Steps to reproduce

  • Download and unpack L4T R32.4.4 (Tegra186_Linux_R32.4.4_aarch64.tbz2)
  • Download and unpack sample rootfs (Tegra_Linux_Sample-Root-Filesystem_R32.4.4_aarch64.tbz2) to the rootfs folder inside Linux_for_Tegra directory using sudo
  • Run (with sudo/root) apply_binaries.sh inside Linux_for_Tegra directory
  • Run (with sudo/root) ./flash.sh -S 15032385536 -R rootfs jetson-tx2 mmcblk0p1
  • Connect to /dev/ttyACM0, finish the OEM configuration
  • Change r32.4 to r32.6 in /etc/apt/sources.list.d/nvidia-l4t-apt-source.list
  • Run apt-get update && apt-get dist-upgrade
  • Reboot

Following error appear in dmesg: [ 1.118088] eqos 2490000.ether_qos: invalid settings : rx-frames must be enabled along with use_riwt in DT. Main ethernet port become non-working. U-boot version is also remain the same: U-Boot 2016.07-g7a7e3f476e (Oct 16 2020 - 12:15:13 -0700)

If I run flash.sh script without specifying -S option (/flash.sh -R rootfs jetson-tx2 mmcblk0p1) then eqos module was OK after reboot and ethernet port is in working state

Rootfs preparation, flashing logs, apt upgrade logs and after-upgrade logs attached.

So what is a way to upgrade my devices which was flashed with specified -S key?

ls-proc-device-tree-ether-qos-4.4.log (2.5 KB)
ls-proc-device-tree-ether-qos-4.6.log (2.5 KB)
after-upgrade-dmesg.log (66.3 KB)
after-upgrade-uart.log (20.4 KB)
dmesg-4.4.log (72.5 KB)
apt-dist-upgrade.log (158.9 KB)
4.4-boot-log (21.2 KB)
flash.sh.log (31.1 KB)
rootfs-preparation.log (8.6 KB)

inb4: device flashed with sdkmanager can be upgraded but sdkmanager run the flash.sh command without -S key

1 Like

Thanks for reporting this.
I believe your test means there is something wrong with bootloader update, which also includes dtb update, when -S is specified. Thus, kernel dtb and your bootloader(uboot/cboot) still remains in jp4.4 version. But the kernel is being changed to 4.6.

Could you also share this file?

nvidia@nvidia-desktop:~$ cat /etc/nv_boot_control.conf

/etc/nv_boot_control.conf after upgrade to 4.6:

TNSPEC 3310-B02-1000-B.0-1-0-jetson-tx2-mmcblk0p1
COMPATIBLE_SPEC 3310-B01---1--jetson-tx2-devkit-
TEGRA_CHIPID 0x18
TEGRA_OTA_BOOT_DEVICE /dev/mmcblk0boot0
TEGRA_OTA_GPT_DEVICE /dev/mmcblk0boot1
1 Like

please also share below log.

/opt/ota_package/*.log"

Hi,

We have confirmed the cause of this issue. In brief, since you have used the “-S” in your flash.sh, this is kind of customization which affects the partition layout.

And since “apt-get upgrade” only installs “default layout” (it is not possible for a general package to know your customization), it turns out failing.

For your case, to update bootloader, you can only use BUP update method mentioned here.

1. Download the r32.6.1 BSP packages
2. Use this package to generate the BUP, just running "sudo ./l4t_generate_soc_bup.sh -p "-S 15032385536" t19x"
3. Copy the BUP to the target device.
4. use nv_update_engine to install it directly.
2 Likes

Hi,

Thank you for information, should I install BUP before or after dist-upgrade?

And If I need to add some custom changes to U-Boot (I need to enable the bootcounter in U-boot) and change the ODMDATA=, then It will be enough to put compiled u-boot.bin binaries into the Linux_for_Tegra/bootloader/t186ref/p2771-0000/500/ and change ODMDATA in p2771-0000.conf.common before generating the BUP?

One more question: it’s possible to flash BUP when running from SATA drive? If rootfs is located on external SATA, then nv_update_engine can’t enable A/B redundancy which is required to update BUP

Hi,

For your ODMDATA and uboot, you need to create BUP (offline mode) on your host side and again put it to your device side.

it’s possible to flash BUP when running from SATA drive? If rootfs is located on external SATA, then nv_update_engine can’t enable A/B redundancy which is required to update BUP

Are you talking about rootfs A/B or even the bootloader A/B is not able to run/update?

Hi,

Yeah, look’s almost fine. I create a BUP on host side using following command:

sudo ./l4t_generate_soc_bup.sh -p "-S 15032385536" -b "jetson-tx2-devkit" t18x

Note about -b "jetson-tx2-devkit" parameter. Without it, nv_update_engine is flashing my board as P3636-0001 (Jetson TX2 NX) instead of P2771-0000-500 (Jetson TX2): I see Model: NVIDIA P3636-0001 messages during U-boot load. Look’s like a bug?


So, the fix for DT is:

On host machine:

  1. (Optionally) apply custom changes: change ODMDATA, put u-boot binaries into Linux_for_Tegra/bootloader/t186ref/p2771-0000/500/
  2. Run BUP generator in Linux_for_Tegra directory: sudo ./l4t_generate_soc_bup.sh -p "-S 15032385536" -b "jetson-tx2-devkit" t18x
  3. Copy bl_update_payload to the device /opt/ota_package directory

On device:

  1. Run apt dist-upgrade
  2. Don’t reboot device
  3. Enable A/B: nv_update_engine -e
  4. Update BUP: nv_update_engine -i
  5. Reboot

Are you talking about rootfs A/B or even the bootloader A/B is not able to run/update?

Even bootloader A/B can’t be enabled if system is booted from SATA (rootfs is placed on /dev/sda3 and root=/dev/sda3 added to extlinux.conf)

# findmnt /
TARGET SOURCE    FSTYPE OPTIONS
/      /dev/sda3 ext4   rw,relatime,data=ordered
# nv_update_engine -i
Nvidia A/B-Redundancy Update tool Version 2.1
null input file!
Init SMD partition failed!
null input file!
Init SMD partition failed!
null input file!
null input file!
A/B has been disabled. Need to enable A/B.
Error: installing bootloader updates failed: -22
# nv_update_engine -e
Nvidia A/B-Redundancy Update tool Version 2.1
null input file!
Init SMD partition failed!
null input file!
Init SMD partition failed!
null input file!
enabling A/B redundancy
null input file!
Enable A/B command failed. It could be due to A/B being enabled already.
Error: Enable A/B redundancy failed!
1 Like

It sounds weird to see this.

Note about -b "jetson-tx2-devkit" parameter. Without it, nv_update_engine is flashing my board as P3636-0001 (Jetson TX2 NX) instead of P2771-0000-500 (Jetson TX2): I see Model: NVIDIA P3636-0001 messages during U-boot load. Look’s like a bug?

What if you use single spec method to create BUP? Will you see this model in uboot?

Yeah, If i use sudo ./l4t_generate_soc_bup.sh -p "-S 15032385536" t18x, without -b flag, then after BUP update I see P3636-0001 in U-boot instead of P2771-0000-500. And my board is definitely TX2, not TX2 NX.

P.S. L4T v 4.6.1 is used to generate BUP

Can we firstly check this on emmc and see if SATA is related to this? I mean not sure if mounting on SATA is causing this problem or not.

BUP update work correctly if system is running from eMMC: both DT and U-boot is updated and eqos Ethernet driver become working again.

I faced with BUP update issue only when system is booted from SATA

Steps to reproduce issue with SATA:

  1. Flash device as usual: ./flash.sh -S 15032385536 -R rootfs jetson-tx2 mmcblk0p1
  2. Format SATA drive partition to ext4 FS (e.g /dev/sda1)
  3. Mount SATA drive to some directory: mount /dev/sda1 /media/sata
  4. Copy current rootfs from eMMC to SATA: cp -ar /!(dev|sys|proc|media|mnt|tmp) /media/sata`
  5. Change /boot/extlinux/extlinux.conf: add root=/dev/sda1
  6. Reboot device
  7. Verify that device is booted from SATA: findmnt / output should show /dev/sda1
  8. Try to run nv_update_engine -e

Ok, just make a summary here.

If we start from emmc, even with “-S” in flash.sh can have fine result, right?

Okay,

If run from eMMC, with -S in flash.sh, then apt dist-upgrade can’t update bootloader and DT. Custom BUP can be flashed using nv_update_engine and device become fully operational

If run from SATA, with -S in flash.sh, then apt dist-upgrade can’t update bootloader and DT too, but custom BUP can’t be flashed, because nv_update_engine can’t enable A/B which is required to flash BUP

|                     | rootfs location|
|---------------------|-------|--------|
|                     | SATA  | eMMC   |
| apt dist-upgrade    |   -   |   -    |
| nv_update_engine -e |   -   |   +    |
| nv_update_engine -i |   -   |   +    |

Note than it both cases (rootfs on eMMC and rootfs on SATA), flashing procedure is completely same: ./flash.sh -S 15032385536 -R rootfs jetson-tx2 mmcblk0p1. I just copy rootfs from eMMC to SATA and point extlinux to it using root=

Ok. Can you file a separate topic for SATA issue? Since the original one is for the “-S” only, this should be new issue.

Okay, got it. So I mark post #12 as solution and topic can be closed. Thank you for the active response.

1 Like