-
Notifications
You must be signed in to change notification settings - Fork 3
Add flashrom job scheduling and flash fd first #130
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
Conversation
Flow
For now tested under qemu Profile example
Flow: Heads update for z790 DDR5 under qemu. |
pre-commit installAlso this change will require updating probably every profile we have in OSFV |
Instead of executing flashrom in place, schedule them and execute one after another. This is basically a workaround for fragmented flashrom parameter logic. This way we know all flashrom jobs before executing them. Signed-off-by: Mateusz Kusiak <mateusz.kusiak@3mdeb.com>
If FD is to be flashed, flash the FD before flashing anything else. The reason is regions are FD dependent. Signed-off-by: Mateusz Kusiak <mateusz.kusiak@3mdeb.com>
Make progress bar standalone to be reusable. It should be used only for drawing the progress bar, and not contain any logic. Signed-off-by: Mateusz Kusiak <mateusz.kusiak@3mdeb.com>
Move drawing progress bar function to dts-functions.sh Signed-off-by: Mateusz Kusiak <mateusz.kusiak@3mdeb.com>
Use progress bar for flashrom jobs instead of printing messages. Add scheduling info for remaining fobs. Signed-off-by: Mateusz Kusiak <mateusz.kusiak@3mdeb.com>
|
Rebased on top of newest main. |
Add progress bar wrapper to avoid code repetition. Signed-off-by: Mateusz Kusiak <mateusz.kusiak@3mdeb.com>
|
This is how it currently looks like: Details
|
For the scheduling to work reliably, the parameters must be stored as arrays, not as strings. Use dynamic arrays for adding flashrom parameters. Additionally improve fd flashing detection mechanism. Signed-off-by: Mateusz Kusiak <mateusz.kusiak@3mdeb.com>
|
Converted to draft, need to run E2E to verify this truly works. |
This commit updates profiles for platforms that need FD flashing in deployment, update and heads transition workflows. The change is that if FD is being flashed, it'll get a dedicated job first. Related to: Dasharo/dts-scripts#130 Signed-off-by: Mateusz Kusiak <mateusz.kusiak@3mdeb.com>
|
Proved this works, need to documment that code though. |
|
There are still couple of places where we are possibly flashing fd once:
Those places also have to be fixed to close issue:
Transition is more important than recovery as we don't even have tests for those. |
Add wrapper function for transition and recovery workflows that detects if fd is being flashed, and if so, runs dedicated flashrom job for FD flashing. Signed-off-by: Mateusz Kusiak <mateusz.kusiak@3mdeb.com>
|
Addressed, though still need to test it. |
This commit updates profiles for platforms that need FD flashing in deployment, update and heads transition workflows. The change is that if FD is being flashed, it'll get a dedicated job first. Related to: Dasharo/dts-scripts#130 Signed-off-by: Mateusz Kusiak <mateusz.kusiak@3mdeb.com>
|
Added some minor documentation to the function, I believe it's ready to review. |
This commit adds a bunch of comment to deploy_firmware() so the function is more readable. Signed-off-by: Mateusz Kusiak <mateusz.kusiak@3mdeb.com>
This commit updates profiles for platforms that need FD flashing in deployment, update and heads transition workflows. The change is that if FD is being flashed, it'll get a dedicated job first. Related to: Dasharo/dts-scripts#130 Signed-off-by: Mateusz Kusiak <mateusz.kusiak@3mdeb.com>
Fixes: Dasharo/dasharo-issues#1592