Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Tegra, Jetpack 5: add Jetson as working target #19

Closed
wants to merge 36 commits into from

Conversation

mwest90
Copy link

@mwest90 mwest90 commented Feb 6, 2024

Minimal working configuration to make Orin and Jetson both work for JetPack 5

The current layer is compatible with Jetpack 4, which
correlates with the L4T 32.x release family. A number of
boards are supported on this, for example
- Jetson TX2
- Jetson Nano
- ...
The newer release family Jetpack 5 correlating with L4T 35.x
introduces a number of breaking changes which cannot be folded
into the existing structure.
To prepare for the support of both families, this moves the
existing layer into a dedicated subdirectory, allowing additional
Tegra-specific layers to be added to the meta-mender-tegra
top level directory.

Changelog: Title
Ticket: None

Signed-off-by: Josef Holzmayr <[email protected]>
This commit continues the refactoring of meta-mender-tegra
to support both Jetpack 4 and Jetpack 5 enabled boards.
The Jetpack 4 based board have been moved to the
tegrademo-mender distro as provided by the OE4T project.
The AGX Orin board is being added as a PoC-quality
board integration on Jetpack 5

Changelog: Title
Ticket: None

Signed-off-by: Josef Holzmayr <[email protected]>
This reflects efcbadb for the
Jetpack 5-based board integration layer.

Signed-off-by: Josef Holzmayr <[email protected]>
Changelog: Title
Ticket: None

Signed-off-by: Josef Holzmayr <[email protected]>
Remove all leftover u-boot references, as it is not
supported anymore on Jetpack 5. See comment:
OE4T#18 (comment)

Signed-off-by: Josef Holzmayr <[email protected]>
Remove outdated init scripts, see comment:
OE4T#18 (comment)

Changelog: Title
Ticket: None

Signed-off-by: Josef Holzmayr <[email protected]>
State scripts referring to TX2 and Nano can be removed.
See also comment: OE4T#18 (comment)

Signed-off-by: Josef Holzmayr <[email protected]>
In Jetpack5, cboot is not used anymore. Remove the
appends which placed an additional dependency on machine-id.

Changelog: Title
Ticket: None

Signed-off-by: Josef Holzmayr <[email protected]>
The TX2 and Nano platforms are not supported on Jetpack 5
anymore, so the respective flash layouts can be removed.

Changelog: Title
Ticket: None

Signed-off-by: Josef Holzmayr <[email protected]>
Copy link
Member

@dwalkes dwalkes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for sharing @mwest90! I've added a few comments here.

meta-mender-tegra/meta-mender-tegra-jetpack5/README.md Outdated Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think rather than duplicate https:/OE4T/meta-mender-community/blob/kirkstone/meta-mender-tegra/meta-mender-tegra-jetpack5/recipes-mender/mender-client/files/tegra234/efi_systemd_machine_id.sh both of these could probably use the same logic/scripts? Or maybe there's a minimal difference I'm not seeing which could be in an override.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is indeed just duplicated, i'm curious though how would you do it in the .bb file?
The work done for tegra234 explicitly set the scripts for 234, meaning they would not be included with any other machines.
But I guess we can just remove the :tegra234 and :tegra194 and have them be included for all devices?
Then rater add specifics for new devices if the "base" we now have does not work.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I guess we can just remove the :tegra234 and :tegra194 and have them be included for all devices? Then rater add specifics for new devices if the "base" we now have does not work.

Yes, exactly

@dwalkes
Copy link
Member

dwalkes commented Feb 6, 2024

Also your commit needs a signoff before it could be upstreamed - see https:/mendersoftware/mender/blob/master/CONTRIBUTING.md#sign-your-work

@Islam-Hussein-11
Copy link

Hi,

I think this line RDEPENDS:${PN}:append = " tegra-boot-tools-updater" in tegra-bup-payload_%.bbappend has to be removed as there is no tegra-boot-tools-updater provided in kirkstone branch it was only found kirkstone-l4t-32.7.x in tegra-boot-tools.inc and not anymore.

secondly I have tested this PR on jetson-xavier-nx-devkit-emmc and I get an error in tegra-minimal-initramfs.bb:do_image_cpio
| [ 5.0388 ] tegrahost_v2 --chip 0x19 --align mce_c10_prod_cr_aligned.bin | [ 5.0441 ] tegrahost_v2 --chip 0x19 0 --magicid MTSM --appendsigheader mce_c10_prod_cr_aligned.bin zerosbk | [ 5.0461 ] Header already present for mce_c10_prod_cr_aligned.bin | [ 5.0564 ] tegrasign_v3.py --key None --list mce_c10_prod_cr_aligned_sigheader.bin_list.xml --pubkeyhash pub_key.key | [ 5.0570 ] Assuming zero filled SBK key | [ 5.0606 ] Warning: pub_key.key is not found | [ 5.0590 ] tegrahost_v2 --chip 0x19 0 --updatesigheader mce_c10_prod_cr_aligned_sigheader.bin.encrypt mce_c10_prod_cr_aligned_sigheader.bin.hash zerosbk | [ 5.0702 ] tegrahost_v2 --chip 0x19 --align mts_c10_prod_cr_aligned.bin | [ 5.0755 ] tegrahost_v2 --chip 0x19 0 --magicid MTSB --appendsigheader mts_c10_prod_cr_aligned.bin zerosbk | [ 5.0776 ] adding BCH for mts_c10_prod_cr_aligned.bin | [ 5.1568 ] tegrasign_v3.py --key None --list mts_c10_prod_cr_aligned_sigheader.bin_list.xml --pubkeyhash pub_key.key | [ 5.1581 ] Assuming zero filled SBK key | [ 5.1678 ] Warning: pub_key.key is not found | [ 5.1663 ] tegrahost_v2 --chip 0x19 0 --updatesigheader mts_c10_prod_cr_aligned_sigheader.bin.encrypt mts_c10_prod_cr_aligned_sigheader.bin.hash zerosbk | [ 5.2137 ] tegrahost_v2 --chip 0x19 --align bpmp-2_t194_aligned.bin | [ 5.2191 ] tegrahost_v2 --chip 0x19 0 --magicid BPMF --ratchet_blob ratchet_blob.bin --appendsigheader bpmp-2_t194_aligned.bin zerosbk | [ 5.2211 ] adding BCH for bpmp-2_t194_aligned.bin | [ 5.2507 ] tegrasign_v3.py --key None --list bpmp-2_t194_aligned_sigheader.bin_list.xml --pubkeyhash pub_key.key | [ 5.2518 ] Assuming zero filled SBK key | [ 5.2570 ] Warning: pub_key.key is not found | [ 5.2554 ] tegrahost_v2 --chip 0x19 0 --updatesigheader bpmp-2_t194_aligned_sigheader.bin.encrypt bpmp-2_t194_aligned_sigheader.bin.hash zerosbk | [ 5.2739 ] tegrahost_v2 --chip 0x19 --align tegra194-a02-bpmp-p3668-a00_lz4_aligned.dtb | [ 5.2793 ] tegrahost_v2 --chip 0x19 0 --magicid BPMD --ratchet_blob ratchet_blob.bin --appendsigheader tegra194-a02-bpmp-p3668-a00_lz4_aligned.dtb zerosbk | [ 5.2814 ] adding BCH for tegra194-a02-bpmp-p3668-a00_lz4_aligned.dtb | [ 5.2909 ] tegrasign_v3.py --key None --list tegra194-a02-bpmp-p3668-a00_lz4_aligned_sigheader.dtb_list.xml --pubkeyhash pub_key.key | [ 5.2917 ] Assuming zero filled SBK key | [ 5.2950 ] Warning: pub_key.key is not found | [ 5.2933 ] tegrahost_v2 --chip 0x19 0 --updatesigheader tegra194-a02-bpmp-p3668-a00_lz4_aligned_sigheader.dtb.encrypt tegra194-a02-bpmp-p3668-a00_lz4_aligned_sigheader.dtb.hash zerosbk | [ 5.2999 ] tegrahost_v2 --chip 0x19 --align spe_t194_aligned.bin | [ 5.3050 ] tegrahost_v2 --chip 0x19 0 --magicid SPEF --ratchet_blob ratchet_blob.bin --appendsigheader spe_t194_aligned.bin zerosbk | [ 5.3070 ] adding BCH for spe_t194_aligned.bin | [ 5.3177 ] tegrasign_v3.py --key None --list spe_t194_aligned_sigheader.bin_list.xml --pubkeyhash pub_key.key | [ 5.3186 ] Assuming zero filled SBK key | [ 5.3218 ] Warning: pub_key.key is not found | [ 5.3202 ] tegrahost_v2 --chip 0x19 0 --updatesigheader spe_t194_aligned_sigheader.bin.encrypt spe_t194_aligned_sigheader.bin.hash zerosbk | [ 5.3283 ] tegrahost_v2 --chip 0x19 --align tos-optee_t194_aligned.img | [ 5.3335 ] tegrahost_v2 --chip 0x19 0 --magicid TOSB --ratchet_blob ratchet_blob.bin --appendsigheader tos-optee_t194_aligned.img zerosbk | [ 5.3355 ] adding BCH for tos-optee_t194_aligned.img | [ 5.3669 ] tegrasign_v3.py --key None --list tos-optee_t194_aligned_sigheader.img_list.xml --pubkeyhash pub_key.key | [ 5.3679 ] Assuming zero filled SBK key | [ 5.3730 ] Warning: pub_key.key is not found | [ 5.3714 ] tegrahost_v2 --chip 0x19 0 --updatesigheader tos-optee_t194_aligned_sigheader.img.encrypt tos-optee_t194_aligned_sigheader.img.hash zerosbk | [ 5.3911 ] tegrahost_v2 --chip 0x19 --align eks_aligned.img | [ 5.3965 ] tegrahost_v2 --chip 0x19 0 --magicid EKSB --ratchet_blob ratchet_blob.bin --appendsigheader eks_aligned.img zerosbk | [ 5.3985 ] adding BCH for eks_aligned.img | [ 5.4074 ] tegrasign_v3.py --key None --list eks_aligned_sigheader.img_list.xml --pubkeyhash pub_key.key | [ 5.4085 ] Assuming zero filled SBK key | [ 5.4117 ] Warning: pub_key.key is not found | [ 5.4101 ] tegrahost_v2 --chip 0x19 0 --updatesigheader eks_aligned_sigheader.img.encrypt eks_aligned_sigheader.img.hash zerosbk | [ 5.4163 ] tegrahost_v2 --chip 0x19 --align tegra194-p3668-all-p3509-0000_aligned.dtb | [ 5.4215 ] tegrahost_v2 --chip 0x19 0 --magicid CDTB --ratchet_blob ratchet_blob.bin --appendsigheader tegra194-p3668-all-p3509-0000_aligned.dtb zerosbk | [ 5.4234 ] adding BCH for tegra194-p3668-all-p3509-0000_aligned.dtb | [ 5.4396 ] tegrasign_v3.py --key None --list tegra194-p3668-all-p3509-0000_aligned_sigheader.dtb_list.xml --pubkeyhash pub_key.key | [ 5.4407 ] Assuming zero filled SBK key | [ 5.4445 ] Warning: pub_key.key is not found | [ 5.4430 ] tegrahost_v2 --chip 0x19 0 --updatesigheader tegra194-p3668-all-p3509-0000_aligned_sigheader.dtb.encrypt tegra194-p3668-all-p3509-0000_aligned_sigheader.dtb.hash zerosbk | [ 5.4536 ] tegrahost_v2 --chip 0x19 --align nvtboot_recovery_cpu_t194_aligned.bin | [ 5.4589 ] tegrahost_v2 --chip 0x19 0 --magicid CPBL --ratchet_blob ratchet_blob.bin --appendsigheader nvtboot_recovery_cpu_t194_aligned.bin zerosbk | [ 5.4609 ] adding BCH for nvtboot_recovery_cpu_t194_aligned.bin | [ 5.4746 ] tegrasign_v3.py --key None --list nvtboot_recovery_cpu_t194_aligned_sigheader.bin_list.xml --pubkeyhash pub_key.key | [ 5.4755 ] Assuming zero filled SBK key | [ 5.4791 ] Warning: pub_key.key is not found | [ 5.4776 ] tegrahost_v2 --chip 0x19 0 --updatesigheader nvtboot_recovery_cpu_t194_aligned_sigheader.bin.encrypt nvtboot_recovery_cpu_t194_aligned_sigheader.bin.hash zerosbk | [ 5.4829 ] Copying signed file in /home/isalm/Desktop/mender-tegra/tegra-demo-distro/build/tmp/work/jetson_xavier_nx_devkit_emmc-oe4t-linux/tegra-minimal-initramfs/1.0-r0/bup-payload/signed | [ 5.5515 ] Copying br bct for multi chains | [ 5.5518 ] Signed BCT for boot chain A is copied to /home/isalm/Desktop/mender-tegra/tegra-demo-distro/build/tmp/work/jetson_xavier_nx_devkit_emmc-oe4t-linux/tegra-minimal-initramfs/1.0-r0/bup-payload/signed/br_bct_BR.bct | | [ 5.5520 ] Signed BCT for boot chain B is copied to /home/isalm/Desktop/mender-tegra/tegra-demo-distro/build/tmp/work/jetson_xavier_nx_devkit_emmc-oe4t-linux/tegra-minimal-initramfs/1.0-r0/bup-payload/signed/br_bct_b_BR.bct | | [ 5.5520 ] Copying BCT backup image bct_backup.img to /home/isalm/Desktop/mender-tegra/tegra-demo-distro/build/tmp/work/jetson_xavier_nx_devkit_emmc-oe4t-linux/tegra-minimal-initramfs/1.0-r0/bup-payload/signed/bct_backup.img | [ 5.5672 ] tegraparser_v2 --pt flash.xml.bin --generateflashindex /home/isalm/Desktop/mender-tegra/tegra-demo-distro/build/tmp/work/jetson_xavier_nx_devkit_emmc-oe4t-linux/tegra-minimal-initramfs/1.0-r0/bup-payload/signed/flash.xml.tmp flash.idx | [ 5.5693 ] File SMDFILE open failed | Error: Return value 19 | Command tegraparser_v2 --pt flash.xml.bin --generateflashindex /home/isalm/Desktop/mender-tegra/tegra-demo-distro/build/tmp/work/jetson_xavier_nx_devkit_emmc-oe4t-linux/tegra-minimal-initramfs/1.0-r0/bup-payload/signed/flash.xml.tmp flash.idx | WARNING: exit code 1 from a shell command. ERROR: Task (/home/isalm/Desktop/mender-tegra/tegra-demo-distro/layers/meta-tegra/recipes-core/images/tegra-minimal-initramfs.bb:do_image_cpio) failed with exit code '1' NOTE: Tasks Summary: Attempted 4927 tasks of which 4926 didn't need to be rerun and 1 failed.

…A partition will be flashed with the appropriate image

Signed-off-by: Iban Rodriguez <[email protected]>
@cakre
Copy link

cakre commented May 2, 2024

Rolling back doesn't seem to work currently. I worked on a fix for that, implementing rollback on top of your branch (switching back to the previous chain when rolling back or not commiting and also not switching the boot chain when rolling back before doing a reboot).

I'd open a PR to your repo if thats ok with you?

@mwest90
Copy link
Author

mwest90 commented May 2, 2024

Rolling back doesn't seem to work currently. I worked on a fix for that, implementing rollback on top of your branch (switching back to the previous chain when rolling back or not commiting and also not switching the boot chain when rolling back before doing a reboot).

I'd open a PR to your repo if thats ok with you?

That would be great!

@cakre
Copy link

cakre commented May 2, 2024

Rolling back doesn't seem to work currently. I worked on a fix for that, implementing rollback on top of your branch (switching back to the previous chain when rolling back or not commiting and also not switching the boot chain when rolling back before doing a reboot).
I'd open a PR to your repo if thats ok with you?

That would be great!

I opened a PR

@irodriguez-veridas
Copy link

I opened a PR

Looks good! I think this also enables adding custom checks to validate an upgrade. Just by adding any ArtifactCommit_Leave_XX where XX<50 it's possible to verify an upgrade and make mender roll it back if a failure is returned, right?

@cakre
Copy link

cakre commented May 6, 2024

I opened a PR

Looks good! I think this also enables adding custom checks to validate an upgrade. Just by adding any ArtifactCommit_Leave_XX where XX<50 it's possible to verify an upgrade and make mender roll it back if a failure is returned, right?

If you want to add custom checks you should do that in ArtifactCommit_Enter or earlier, since it's too late to roll back if we already committed the update. (See mender docs)

The state script the PR added just serves to make the partition switch persistent when we are sure, that the update was successful (ArtifactCommit_Leave is the last "step" thats executed if everything went alright)

@irodriguez-veridas
Copy link

If you want to add custom checks you should do that in ArtifactCommit_Enter or earlier, since it's too late to roll back if we already committed the update. (See mender docs)

Oh, yes, you are totally right. Even if partition switch is not verified it would be committed from mender point of view. Thanks!

@dwalkes
Copy link
Member

dwalkes commented Jun 25, 2024

Hey everyone thanks for all the work on this. I haven't kept up on the overall status, can someone summarize what is or isn't working and what would need to happen before this could be upstreamed, if anything?

I also noticed an option at https://hub.mender.io/t/swupdate/6953/2 which could be interesting for mender integration, since there is already a working swupdate example at https:/OE4T/tegra-demo-distro?tab=readme-ov-file#update-image-demo

@maxekman
Copy link

For me I have successfully compiled and flashed a Syslogic Jetson Xavier box (lots of custom board support etc, so I can’t say anything about the dev kit). I have not yet had time to test a Mender update on it, but it should be fairly easy to do.

I plan to do the same test on a Syslogic Jetson Orin after I’m happy with the Xavier.

That is a small summary from my side at least.

@irodriguez-veridas
Copy link

Hey everyone thanks for all the work on this. I haven't kept up on the overall status, can someone summarize what is or isn't working and what would need to happen before this could be upstreamed, if anything?

Hi Dan! From my side I can confirm that Orin Nano devkit is working. I don't have an AGX Xavier devkit or AGX Orin devkit to test it. I was waiting for @mwest90 to do it but he is missing since some time ago. According to the work done by @maxekman I suppose it should work for AGX Xavier devkit but it would be better to confirm it.

Additionally, I think @maxekman has used this branch on my repository to do the tests. That branch includes using default redundant layout provided by nVidia and solves issue with reserved space for nVidia partitions. @maxekman If you confirm this is the branch you have used I will PR it to @mwest90 branch so that changes are added to this PR. You can also then PR your changes to correct partition offsets, BTW, have you discovered why these offsets were so high?

I also noticed an option at https://hub.mender.io/t/swupdate/6953/2 which could be interesting for mender integration, since there is already a working swupdate example at https:/OE4T/tegra-demo-distro?tab=readme-ov-file#update-image-demo

It may be interesting testing it. Anyway, I think most of the changes added in this PR would be needed anyway since in the end mender client will be the responsible of download the swupdate package, reboot the system, verify that the upgrade has completed correctly and rollback if it has failed.

@dwalkes
Copy link
Member

dwalkes commented Jul 19, 2024

@TheYoctoJester did you already have work done to handle the conflicts now that we've rebased the kirkstone branch on upstream?

@TheYoctoJester
Copy link

HI @dwalkes yup, I've prepared a rebased state with the resolved conflicts (to my best knowledge) at https:/TheYoctoJester/meta-mender-community/tree/mwest90-working-jetson-orin. The build pipeline has just started, hopefully no breakage emerges. As I can't modify this PR, I guess you or @mwest90 will have to do the force push.

@cakre
Copy link

cakre commented Jul 22, 2024

8756a1b Removed edk2-firmware-tegra_%.bbappend completely resulting in the updated L4TConfiguration-[...].dtsi not being applied which includes a change to the retry count needed for rollbacks to work properly

Gave this PR a rebase onto the merged state of kirkstone (#21),

Thanks @TheYoctoJester added a question there about how to proceed with that one.

anything I can help without having the actual hardware?

I don't think so

anything we still need to address?

Probably just the most recent comment from @cakre as well as some testing on Jetpack 4 with hardware.

@cakre

You mean the change here: https:/OE4T/meta-mender-community/pull/19/files#diff-94b9a1f2bb0917c8a8df1c2394cdab37f0c8a8a7138aece71a81cb986224d035R29-R32 is needed to make a failed boot after upgrade result in a rollback. Are you testing this with a power cycle during reboot and after upgrade?

Yes this causes the jetson to fall back to the old boot chain after one try (which is expected by mender). Powerloss is not detected and won't cause the update to "fail" since coldboots don't decrease the retry counter. I don't think there is anything we can do about that

@@ -0,0 +1,2 @@
FILESEXTRAPATHS:prepend := "${THISDIR}/${BPN}:"
# RDEPENDS:${PN} += "tegra-redundant-boot-nvbootctrl"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason to keep this commented out line?

@@ -0,0 +1,2 @@
RDEPENDS:${PN}:remove = "tegra-redundant-boot"
# RDEPENDS:${PN}:append = " tegra-boot-tools-updater"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason to keep this commented out line?

- AGX Xavier
- Orin Nano

Visit the individual board links above for more information on status of the
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Contrary to the readme for jetpack 4, this readme does not add links for the boards. So it's probably best to remove this sentence to not cause confusion.

@mwest90
Copy link
Author

mwest90 commented Jul 23, 2024

8756a1b Removed edk2-firmware-tegra_%.bbappend completely resulting in the updated L4TConfiguration-[...].dtsi not being applied which includes a change to the retry count needed for rollbacks to work properly

Gave this PR a rebase onto the merged state of kirkstone (#21),

Thanks @TheYoctoJester added a question there about how to proceed with that one.

anything I can help without having the actual hardware?

I don't think so

anything we still need to address?

Probably just the most recent comment from @cakre as well as some testing on Jetpack 4 with hardware.
@cakre
You mean the change here: https:/OE4T/meta-mender-community/pull/19/files#diff-94b9a1f2bb0917c8a8df1c2394cdab37f0c8a8a7138aece71a81cb986224d035R29-R32 is needed to make a failed boot after upgrade result in a rollback. Are you testing this with a power cycle during reboot and after upgrade?

Yes this causes the jetson to fall back to the old boot chain after one try (which is expected by mender). Powerloss is not detected and won't cause the update to "fail" since coldboots don't decrease the retry counter. I don't think there is anything we can do about that

@cakre @dwalkes I will bring back the edk2-firmware-tegra_%.bbappend with the FILESEXTRAPATHS section then.
@cakre do you have a good procedure for testing this?

@cakre
Copy link

cakre commented Jul 25, 2024

8756a1b Removed edk2-firmware-tegra_%.bbappend completely resulting in the updated L4TConfiguration-[...].dtsi not being applied which includes a change to the retry count needed for rollbacks to work properly

Gave this PR a rebase onto the merged state of kirkstone (#21),

Thanks @TheYoctoJester added a question there about how to proceed with that one.

anything I can help without having the actual hardware?

I don't think so

anything we still need to address?

Probably just the most recent comment from @cakre as well as some testing on Jetpack 4 with hardware.
@cakre
You mean the change here: https:/OE4T/meta-mender-community/pull/19/files#diff-94b9a1f2bb0917c8a8df1c2394cdab37f0c8a8a7138aece71a81cb986224d035R29-R32 is needed to make a failed boot after upgrade result in a rollback. Are you testing this with a power cycle during reboot and after upgrade?

Yes this causes the jetson to fall back to the old boot chain after one try (which is expected by mender). Powerloss is not detected and won't cause the update to "fail" since coldboots don't decrease the retry counter. I don't think there is anything we can do about that

@cakre @dwalkes I will bring back the edk2-firmware-tegra_%.bbappend with the FILESEXTRAPATHS section then. @cakre do you have a good procedure for testing this?

nvbootctrl dump-slots-info -t rootfs tells you the retry_count for each rootfs slot. It should be at 1 for both slots.

If you want to test the mender update/rollback:
Install the mender file and reboot, then you should be on the other slot. You can check that with the nvbootctrl command above. It should also show retry_count=0 for your current slot. retry_count gets reset to 1 when you mender commit. If you want to test the rollback feature just reboot again instead of commiting and you should be back on the previous slot. nvbootcontrol should now claim the other slot is unbootable

Signed-off-by: Carlo Kretzschmann <[email protected]>
@cakre
Copy link

cakre commented Jul 25, 2024

I noticed that mender-client-systemd-machine-id.service fails with mender 4 with this PR.
I opened another PR fix this.

@zach-welch-aquabyte
Copy link

I have a WIP branch to upgrade this branch to scarthgap at zach-welch-aquabyte/meta-mender-community:scarthgap-tegra-jetpack5.

With those changes, I can build an image that boots on my custom Orin NX system, and I have successfully performed a couple of upgrades to prove to myself that it works as expected. Thanks to everyone for all the hard work getting this branch into working shape. Once this current PR/branch lands, I can rebase my changes and push a new PR to merge this into the scarthgap branch, unless someone else wants to take the lead on that.

@TheYoctoJester
Copy link

I have a WIP branch to upgrade this branch to scarthgap at zach-welch-aquabyte/meta-mender-community:scarthgap-tegra-jetpack5.

With those changes, I can build an image that boots on my custom Orin NX system, and I have successfully performed a couple of upgrades to prove to myself that it works as expected. Thanks to everyone for all the hard work getting this branch into working shape. Once this current PR/branch lands, I can rebase my changes and push a new PR to merge this into the scarthgap branch, unless someone else wants to take the lead on that.

Very cool, thats awesome news!

The base of meta-mender-tegra/meta-mender-tegra-jetpack5 has already been aligned with upstream on the repository, and I have prepared a rebase of this PR which solves the conflicts. Hopefully I can get that updated to the latest state later today.

For movig forward, we would need somebody with push permissions to this PR to take it in, and unless new issues are found I think we should be good to merge?

For the scarthgap port, I generally would think it should be merged after that, and we need to make sure all of the (relevant) bits and pieces are also there so we don't end up with needlessly diverging feature sets or compatibilities. Thoughts @mwest90 & @dwalkes

@dwalkes
Copy link
Member

dwalkes commented Jul 27, 2024

I have prepared a rebase of this PR which solves the conflicts. Hopefully I can get that updated to the latest state later today.

Great!

For moving forward, we would need somebody with push permissions to this PR to take it in, and unless new issues are found I think we should be good to merge?

Agreed, or we could just bypass this repo at this point since everything is just upstream and since you are doing the rebase anyway, just close based on your new PR and link here for the history if anyone needs or wants this.

For the scarthgap port, I generally would think it should be merged after that, and we need to make sure all of the (relevant) bits and pieces are also there so we don't end up with needlessly diverging feature sets or compatibilities. Thoughts @mwest90 & @dwalkes

Agree... if it's ready to go as-is we don't need to target OE4T/meta-mender-community at all, we can just go upstream. The only reason to target here IMHO would be if we need more help to get it ready for all machines or rework on the latest of relevant oe4t/meta-tegra branches.

@dwalkes
Copy link
Member

dwalkes commented Jul 27, 2024

I just reviewed all the discussions, looks like there are three minor ones from @apbr which aren't yet incorporated in the branch from @mwest90. @TheYoctoJester if you have a branch in progress which is rebased you might want to just handle there. See the ones starting at #19 (comment)

@TheYoctoJester
Copy link

I just reviewed all the discussions, looks like there are three minor ones from @apbr which aren't yet incorporated in the branch from @mwest90. @TheYoctoJester if you have a branch in progress which is rebased you might want to just handle there. See the ones starting at #19 (comment)

Sure, can do that.

@TheYoctoJester
Copy link

@dwalkes @mwest90 done. Therefore, #22 technically supersedes this PR.

@TheYoctoJester
Copy link

Agree... if it's ready to go as-is we don't need to target OE4T/meta-mender-community at all, we can just go upstream. The only reason to target here IMHO would be if we need more help to get it ready for all machines or rework on the latest of relevant oe4t/meta-tegra branches.

Sorry, missed that comment. So if that's the preferred way please comment at mendersoftware#394 (specifically @mwest90), then we can get it in right away.

@TheYoctoJester
Copy link

@maxekman I have just noticed that your commit is not signed-off. So for the merge to upstream, do you want me to remove it and you resubmit, or should I just remove the snippet myself in a new commit?

@cakre
Copy link

cakre commented Jul 29, 2024

I just noticed another issue with mender 4. Should a open a PR against @mwest90 repo or rather against yours @TheYoctoJester ?

@TheYoctoJester
Copy link

TheYoctoJester commented Jul 29, 2024

I just noticed another issue with mender 4. Should a open a PR against @mwest90 repo or rather against yours @TheYoctoJester ?

As https:/TheYoctoJester/meta-mender-community/tree/mwest90-working-jetson-orin already contains the fixed commits by @mwest90 and is rebased, I'd actually like to continue there. There's just one minor outstanding nitpick by now, then we can merge it right to upstream.

EDIT: @cakre the branch is ready for merge by now, should we wait for the fix or merge now, then maintain in-tree?

@TheYoctoJester
Copy link

@mwest90 guess we should close this PR then?

@mwest90
Copy link
Author

mwest90 commented Jul 29, 2024

@TheYoctoJester I agree, I will close this one now and any more changes should be targeted to yours.

@TheYoctoJester
Copy link

I have a WIP branch to upgrade this branch to scarthgap at zach-welch-aquabyte/meta-mender-community:scarthgap-tegra-jetpack5.

With those changes, I can build an image that boots on my custom Orin NX system, and I have successfully performed a couple of upgrades to prove to myself that it works as expected. Thanks to everyone for all the hard work getting this branch into working shape. Once this current PR/branch lands, I can rebase my changes and push a new PR to merge this into the scarthgap branch, unless someone else wants to take the lead on that.

After looking into this (at least a bit), it seems that scarthgap will have a JP-versioning split 5 and 6 too. So should we plan for a structure here too?

@mwest90 mwest90 closed this Jul 29, 2024
@dwalkes
Copy link
Member

dwalkes commented Jul 29, 2024

it seems that scarthgap will have a JP-versioning split 5 and 6 too. So should we plan for a structure here too?

I'm hopeful we won't need to go through this for Jetpack 5 to 6 as the change from 5 to 6 in this area is much smaller than the change from 4-5. From 4-5 they completely changed the boot components and added UEFI. The same capsule update mechanism is in use between 5-6.

@dwalkes
Copy link
Member

dwalkes commented Jul 29, 2024

Closed in favor of mendersoftware#394 instead.

@cmcquinn
Copy link

Could anyone share their setup for using mender with the tegra-demo-distro on Jetpack 5? I am in the process of porting our JP4-based tegra distro to JP5 and it would be handy to have an example mender config.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.