-
Notifications
You must be signed in to change notification settings - Fork 4
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
feature(v3.7.x): bootcontrol: refactor jetson-cboot, add new firmware update support #287
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… slot on unified_ab dev
Bodong-Yang
changed the title
feature(v3.7.x): bootcontrol: add jetson-cboot
feature(v3.7.x): bootcontrol: add jetson-cboot with new firmware update support
Apr 18, 2024
commit f73c6d0 Author: Bodong Yang <[email protected]> Date: Mon Apr 22 00:16:45 2024 +0900 fix(v3.7.x): not merging available_ecu_ids from child ECUs status resp again (#290) This PR fixes an unexpected implementation details which prevents the available_ecu_ids for actually behaving as expected. This is caused by: * ota_client_stub module merges the available_ecu_ids from sub ECU's status response. * ecu_info parsing logic has an implicit implementation detail for backward compatibility, which when available_ecu_ids is not defined in the ecu_info.yaml, add this ECU id into this field. The above effectively disabling the functionality of available_ecu_ids, unless the corresponding ECU contacts that don't need OTA also being commented out in ecu_info.yaml. With this PR, now the available_ecu_ids field should work as expected, and the behavior aligns with the documentation, which only available_ecu_ids from the main ECU is respected.
6 tasks
Bodong-Yang
added a commit
that referenced
this pull request
Apr 25, 2024
This PR does the following things: 1. refines the common module's subprocess wrapper methods. 2. refines and simplify the boot_control.common.CMDHelperFuncs implementation a lot. 3. cleanup and remove boot_contro.errors, now each boot controller implementation has their own error types. 4. use mount slot helper's prepare_standby_dev instead of each boot controller's prepare_standby_dev method. 5. integrate the new CMDHelperFuncs to each boot controller and fix up test files accordingly. NOTE that cboot boot controller implementation is temporarily removed, it will be added back in #287 .
commit 727ebdd Author: Bodong Yang <[email protected]> Date: Thu Apr 25 12:03:09 2024 +0900 refine(v3.7.x): refine bootctrl.common CMDHelperFuncs (#289) This PR does the following things: 1. refines the common module's subprocess wrapper methods. 2. refines and simplify the boot_control.common.CMDHelperFuncs implementation a lot. 3. cleanup and remove boot_contro.errors, now each boot controller implementation has their own error types. 4. use mount slot helper's prepare_standby_dev instead of each boot controller's prepare_standby_dev method. 5. integrate the new CMDHelperFuncs to each boot controller and fix up test files accordingly. NOTE that cboot boot controller implementation is temporarily removed, it will be added back in #287 .
Bodong-Yang
changed the title
feature(v3.7.x): bootcontrol: add jetson-cboot with new firmware update support
feature(v3.7.x): bootcontrol: refactor jetson-cboot, add new firmware update support
Apr 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR re-introduces boot control implementation for jetson device boots with jetson-cboot(for BSP < R34), along with new firmware update mechanism and firmware version control mechanism.
With this PR, NVIDIA nv_update_engine is used to apply the ECU's firmware update, along with firmware version control. The firmware update is fully supported, including bootloader updates.
This PR deprecates the old firmware update mechanism introduced in #204 .
Check list
Docs
jetson-cboot boot control design
Test
There are three bench tests for this version of otaclient:
https://tier4.atlassian.net/wiki/spaces/WEB/pages/3069903366
https://tier4.atlassian.net/wiki/spaces/WEB/pages/3088712741
https://tier4.atlassian.net/wiki/spaces/WEB/pages/3095494738
Changes
Behavior changes
Does this PR introduce behavior change(s)?
Now jetson-cboot controller will keep records of the current firmware version, if the standby slot's firmware version is equal or newer than the OTA image's one, no firmware update will occur.
Breaking change
Does this PR introduce breaking change?
Old manual firmware update mechanism is deprecated in flavor of the new firmware update mechanism with version control.
Related links & tickets
https://tier4.atlassian.net/browse/RT4-9342