-
Notifications
You must be signed in to change notification settings - Fork 5
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
Conversation
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 <jester@theyoctojester.info>
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 <jester@theyoctojester.info>
This reflects efcbadb for the Jetpack 5-based board integration layer. Signed-off-by: Josef Holzmayr <jester@theyoctojester.info>
Changelog: Title Ticket: None Signed-off-by: Josef Holzmayr <jester@theyoctojester.info>
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 <jester@theyoctojester.info>
Remove outdated init scripts, see comment: OE4T#18 (comment) Changelog: Title Ticket: None Signed-off-by: Josef Holzmayr <jester@theyoctojester.info>
State scripts referring to TX2 and Nano can be removed. See also comment: OE4T#18 (comment) Signed-off-by: Josef Holzmayr <jester@theyoctojester.info>
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 <jester@theyoctojester.info>
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 <jester@theyoctojester.info>
There was a problem hiding this 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.
...gra-jetpack5/recipes-bsp/tegra-binaries/mender-custom-flash-layout/tegra194/flash_mender.xml
Outdated
Show resolved
Hide resolved
...a/meta-mender-tegra-jetpack5/recipes-mender/tegra-state-scripts/files/tegra194/switch-rootfs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
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://github.com/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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
...a/meta-mender-tegra-jetpack5/recipes-mender/tegra-state-scripts/files/tegra194/switch-rootfs
Outdated
Show resolved
Hide resolved
Also your commit needs a signoff before it could be upstreamed - see https://github.com/mendersoftware/mender/blob/master/CONTRIBUTING.md#sign-your-work |
meta-mender-tegra/meta-mender-tegra-jetpack5/classes/tegra-mender-setup.bbclass
Show resolved
Hide resolved
3150349
to
ba6781e
Compare
Signed-off-by: Marius Westgaard <marius.westgaard@1x.tech>
Signed-off-by: Marius Westgaard <marius.westgaard@1x.tech>
Signed-off-by: Marius Westgaard <marius.westgaard@1x.tech>
ba6781e
to
0e3899b
Compare
meta-mender-tegra/meta-mender-tegra-jetpack5/classes/tegra-mender-setup.bbclass
Show resolved
Hide resolved
Hi, I think this line 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 |
…A partition will be flashed with the appropriate image Signed-off-by: Iban Rodriguez <irodriguez@das-gate.com>
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 |
Looks good! I think this also enables adding custom checks to validate an upgrade. Just by adding any |
If you want to add custom checks you should do that in The state script the PR added just serves to make the partition switch persistent when we are sure, that the update was successful ( |
Oh, yes, you are totally right. Even if partition switch is not verified it would be committed from mender point of view. Thanks! |
meta-mender-tegra/meta-mender-tegra-jetpack5/classes/tegra-mender-setup.bbclass
Show resolved
Hide resolved
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://github.com/OE4T/tegra-demo-distro?tab=readme-ov-file#update-image-demo |
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. |
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?
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. |
@TheYoctoJester did you already have work done to handle the conflicts now that we've rebased the kirkstone branch on upstream? |
HI @dwalkes yup, I've prepared a rebased state with the resolved conflicts (to my best knowledge) at https://github.com/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. |
8756a1b Removed
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" |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
@cakre @dwalkes I will bring back the |
If you want to test the mender update/rollback: |
Signed-off-by: Carlo Kretzschmann <kretzschmann@3dvisionlabs.com>
I noticed that |
Mender 4 support
Signed-off-by: Marius Westgaard <marius.westgaard@1x.tech>
I have a WIP branch to upgrade this branch to 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 |
Very cool, thats awesome news! The base of 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 |
Great!
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.
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. |
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. |
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. |
@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? |
I just noticed another issue with mender 4. Should a open a PR against @mwest90 repo or rather against yours @TheYoctoJester ? |
As https://github.com/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? |
@mwest90 guess we should close this PR then? |
@TheYoctoJester I agree, I will close this one now and any more changes should be targeted to yours. |
After looking into this (at least a bit), it seems that |
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. |
Closed in favor of mendersoftware#394 instead. |
Could anyone share their setup for using mender with the |
Minimal working configuration to make Orin and Jetson both work for JetPack 5