Mender standalone update from warrior to zeus (or dunfell)

Hi,
I’m starting upgrading my custom jetson-tx2 project from warrior to zeus (or hopefully dunfell). My current project generates payload files that supports only single board revision and I think that prevents upgrading to newer yocto project. Is it possible to build zeus or dunfell project such as they are compatible with my warrior project.

Hi @hoostol I’m not sure what your issue is. Did you try to do an update? Do you have error logs? It’s possible that you will need a state script or something to bootstrap between major releases but it is definitely feasible to do so.

Drew

Thanks for your answer

my issue is that after updating my board refuses to boot.

Starting kernel …

[ 0.000000] Booting Linux on physical CPU 0x100
[ 0.000000] Linux version 4.9.140-l4t-r32.3.1+g48c6aaffbe37 (oe-user@oe-host) (gcc version 9.2.0 (GCC) ) #1 SMP PREEMPT Wed Apr 14 08:45:00 UTC 2021
[ 0.000000] Boot CPU: AArch64 Processor [411fd073]
[ 0.000000] OF: fdt:memory scan node memory@80000000, reg size 16416,
[ 0.000000] OF: fdt: - 80000000 , 70000000
[ 0.000000] OF: fdt: - f0200000 , 185600000
[ 0.000000] OF: fdt: - 275e00000 , 200000
[ 0.000000] OF: fdt: - 276600000 , 200000
[ 0.000000] OF: fdt: - 277000000 , 200000
[ 0.000000] earlycon: uart8250 at MMIO32 0x0000000003100000 (options ‘’)
[ 0.000000] bootconsole [uart8250] enabled
[ 0.000000] Found tegra_fbmem2: 00800000@9607d000
[ 0.000000] Found lut_mem2: 00002008@9607a000
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb0_carveout’: base 0x0000000000000000, size 0 MiB
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb0_carveout’: base 0x0000000000000000, size 0 MiB
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb2_carveout’: base 0x0000000000000000, size 0 MiB
[ 0.000000] OF: fdt:Reserved memory: failed to reserve memory for node ‘fb2_carveout’: base 0x0000000000000000, size 0 MiB
[ 0.000000] OF: reserved mem: initialized node ramoops_carveout, compatible id nvidia,ramoops
[ 0.000000] cma: Reserved 64 MiB at 0x00000000fc000000
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv1.0 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: MIGRATE_INFO_TYPE not supported.
[ 0.000000] psci: SMC Calling Convention v1.1
[ 0.000000] percpu: Embedded 25 pages/cpu @ffffffc1f7023000 s61592 r8192 d32616 u102400
[ 0.000000] Speculative Store Bypass Disable mitigation not required
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2020917
[ 0.000000] Kernel command line: video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt tegra_fbmem2=0x800000@0x9607d000 lut_mem2=0x2008@0x9607a000 usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix=_b boot.ratchetvalues=0.983071.1 bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 root=/dev/mmcblk0p1 rw rootwait
[ 0.000000] log_buf_len individual max cpu contribution: 32768 bytes
[ 0.000000] log_buf_len total cpu_extra contributions: 163840 bytes
[ 0.000000] log_buf_len min size: 32768 bytes
[ 0.000000] log_buf_len: 262144 bytes
[ 0.000000] early log buf free: 29684(90%)
[ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.000000] Memory: 7962072K/8212468K available (14974K kernel code, 2912K rwdata, 9844K rodata, 8576K init, 609K bss, 184860K reserved, 65536K cma-reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffffff8000000000 - 0xffffff8008000000 ( 128 MB)
[ 0.000000] vmalloc : 0xffffff8008000000 - 0xffffffbebfff0000 ( 250 GB)
[ 0.000000] .text : 0xffffff8008080000 - 0xffffff8008f20000 ( 14976 KB)
[ 0.000000] .rodata : 0xffffff8008f20000 - 0xffffff80098d0000 ( 9920 KB)
[ 0.000000] .init : 0xffffff80098d0000 - 0xffffff800a130000 ( 8576 KB)
[ 0.000000] .data : 0xffffff800a130000 - 0xffffff800a408008 ( 2913 KB)
[ 0.000000] .bss : 0xffffff800a408008 - 0xffffff800a4a075c ( 610 KB)
[ 0.000000] fixed : 0xffffffbefe7fd000 - 0xffffffbefec00000 ( 4108 KB)
[ 0.000000] PCI I/O : 0xffffffbefee00000 - 0xffffffbeffe00000 ( 16 MB)
[ 0.000000] vmemmap : 0xffffffbf00000000 - 0xffffffc000000000 ( 4 GB maximum)
[ 0.000000] 0xffffffbf00000000 - 0xffffffbf07dc8000 ( 125 MB actual)
[ 0.000000] memory : 0xffffffc000000000 - 0xffffffc1f7200000 ( 8050 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] Build-time adjustment of leaf fanout to 64.
[ 0.000000] RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=6.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=6
[ 0.000000] NR_IRQS:64 nr_irqs:64 0
[ 0.000000] GIC: Using split EOI/Deactivate mode
[ 0.000000] arm_arch_timer: Architected cp15 timer(s) running at 31.25MHz (phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xe6a171046, max_idle_ns: 881590405314 ns
[ 0.000003] sched_clock: 56 bits at 31MHz, resolution 32ns, wraps every 4398046511088ns
[ 0.009435] Console: colour dummy device 80x25
[ 0.014095] console [tty0] enabled
[ 0.017651] bootconsole [uart8250] disabled

Hi @hoostol that is indeed strange. You get no further output? I would expect at least an error mounting the root filesystems. But perhaps the bootconsole [uart8250] disabled is interfering with that.

@lluiscampos are there any known issues updating from warrior to newer?

@dwalkes @madisox any thing in the Tegra BSP that could cause this?

@hoostol @lluiscampos
Due to partition changes across L4T/Jetpack releases, mender upgrading (or anything other than tegraflashing) between yocto branches is currently not supported. Nvidia has some changes they are introducing to support this with L4T r32.6 however there will be some work to do in order to support with mender or any other meta-tegra based update mechanim. Nvidia is offering early access to developers with an NDA for anyone who wants to help implement support for meta-tegra based distributions.

You can see some notes about this in our March OE4T meeting at OE4T Meeting Notes March 2021 and this will likely be a topic discussed there going forward. If you are interested I suggest watching Monthly Meetings · Discussion #515 · OE4T/meta-tegra · GitHub for updates.

As far as the console output goes, I don’t see console=ttyS0,115200 in the kernel command line, and from this at the end of the excerpt:

[ 0.014095] console [tty0] enabled

I’d say any further kernel output is being directed to the graphical console. If you need serial console output, you should check on the setting of KERNEL_ARGS in your custom build setup.

Thank you for the clarification.

If I understand correctly, I can’t upgrade my warrior board to zeus or dunfell without tegra flashing.
And just to be sure, newer Jetpacks are incompatible with warrior branch due to the partition layout changes (zeus or dunfell won’t work with the older (warrior) partition layout).

And just to be sure, newer Jetpacks are incompatible with warrior branch due to the partition layout changes (zeus or dunfell won’t work with the older (warrior) partition layout).

I think that’s true as a general statement. I’ve got some history of the changes across different products/revisions in my notes at Mender Tegra - Nvidia Jetson Flash Layout - Shared Publicly - Google Sheets in case that’s useful. If you are using uboot on TX2 (and I suspect you are because I don’t think support for cboot came in until after warrior) I know the uboot partition has moved around. There are probably others which have moved around too or have been resized in different ways. @madisox has a commit in the massive zeus refactor he did at RFC: extend support to all Jetsons by madisongh · Pull Request #10 · Trellis-Logic/meta-mender-community · GitHub which attempts to support migrating uboot variables across updates and which isn’t fully tested but might be a good place to start if you want to try supporting this - see RFC: extend support to all Jetsons by madisongh · Pull Request #10 · Trellis-Logic/meta-mender-community · GitHub.

I’ve opened Mender upgrades across L4T releases (and yocto branches) are not currently supported · Issue #14 · OE4T/meta-mender-community · GitHub as a place to track this since this is linked from all board integration pages.