[opentitantool] Ship updated firmware for HyperDebug #25917
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
jesultra
added
SW:opentitantool
CherryPick:earlgrey_es_sival
jesultra
force-pushed
the
hyperdebug_firmware
branch
from
3c53d5b to
6a3b1b7
Compare
pamaury
approved these changes
Jan 17, 2025
jesultra
force-pushed
the
hyperdebug_firmware
branch
from
6a3b1b7 to
0a4091d
Compare
|
I suspect that this firmware is unstable, as it seems HyperDebug restarted during CI testing. This is unfortunate, since OpenTitanTool will not automatically downgrade firmware, so now the affected CI machines have faulty HyperDebug firmware which will affect other "innocent" PRs. I have created PR #25934 to make OpenTitanTool automatically downgrade. |
jesultra
added a commit
to jesultra/opentitan
that referenced
this pull request
Jan 18, 2025
This reverts commit 7a0134a, such that opentitantool no longer requires the `--force` switch in order to downgrade firmware with `opentitantool transport update-firmware`. Instead, opentitantool will be back to the original behavior of overwriting firmware in any case when the version number does not match exactly. The original reason for not downgrading was that our branches had diverged, such that they had different firmware versions, resulting in CI machines constantly upgrading/downgrading as CI runs from different branches were scheduled. PR lowRISC#25917, however introduced a faulty HyperDebug firmware with never version number, which is now on a number of CI machines, and will not be downgraded automatically, with the result that "innocent" other PRs will have CI failures. I think it is clear that we should avoid such excessive flashing by keeping the HyperDebug firmware version in sync between branches. (We do not need to keep all of opentitantool logic in sync, just the built-in firmware version.) For now, in order to avoid CI failures, we should merge this PR, and accept some upgrading/downgrading. Change-Id: I57739777ab3d86fa7e0375834cf9140e8e6ac984 Signed-off-by: Jes B. Klinke <[email protected]>
jesultra
added a commit
that referenced
this pull request
Jan 18, 2025
This reverts commit 7a0134a, such that opentitantool no longer requires the `--force` switch in order to downgrade firmware with `opentitantool transport update-firmware`. Instead, opentitantool will be back to the original behavior of overwriting firmware in any case when the version number does not match exactly. The original reason for not downgrading was that our branches had diverged, such that they had different firmware versions, resulting in CI machines constantly upgrading/downgrading as CI runs from different branches were scheduled. PR #25917, however introduced a faulty HyperDebug firmware with never version number, which is now on a number of CI machines, and will not be downgraded automatically, with the result that "innocent" other PRs will have CI failures. I think it is clear that we should avoid such excessive flashing by keeping the HyperDebug firmware version in sync between branches. (We do not need to keep all of opentitantool logic in sync, just the built-in firmware version.) For now, in order to avoid CI failures, we should merge this PR, and accept some upgrading/downgrading. Change-Id: I57739777ab3d86fa7e0375834cf9140e8e6ac984 Signed-off-by: Jes B. Klinke <[email protected]>
github-actions bot
pushed a commit
that referenced
this pull request
Jan 18, 2025
This reverts commit 7a0134a, such that opentitantool no longer requires the `--force` switch in order to downgrade firmware with `opentitantool transport update-firmware`. Instead, opentitantool will be back to the original behavior of overwriting firmware in any case when the version number does not match exactly. The original reason for not downgrading was that our branches had diverged, such that they had different firmware versions, resulting in CI machines constantly upgrading/downgrading as CI runs from different branches were scheduled. PR #25917, however introduced a faulty HyperDebug firmware with never version number, which is now on a number of CI machines, and will not be downgraded automatically, with the result that "innocent" other PRs will have CI failures. I think it is clear that we should avoid such excessive flashing by keeping the HyperDebug firmware version in sync between branches. (We do not need to keep all of opentitantool logic in sync, just the built-in firmware version.) For now, in order to avoid CI failures, we should merge this PR, and accept some upgrading/downgrading. Change-Id: I57739777ab3d86fa7e0375834cf9140e8e6ac984 Signed-off-by: Jes B. Klinke <[email protected]> (cherry picked from commit 2667a3a)
github-actions bot
pushed a commit
that referenced
this pull request
Jan 18, 2025
This reverts commit 7a0134a, such that opentitantool no longer requires the `--force` switch in order to downgrade firmware with `opentitantool transport update-firmware`. Instead, opentitantool will be back to the original behavior of overwriting firmware in any case when the version number does not match exactly. The original reason for not downgrading was that our branches had diverged, such that they had different firmware versions, resulting in CI machines constantly upgrading/downgrading as CI runs from different branches were scheduled. PR #25917, however introduced a faulty HyperDebug firmware with never version number, which is now on a number of CI machines, and will not be downgraded automatically, with the result that "innocent" other PRs will have CI failures. I think it is clear that we should avoid such excessive flashing by keeping the HyperDebug firmware version in sync between branches. (We do not need to keep all of opentitantool logic in sync, just the built-in firmware version.) For now, in order to avoid CI failures, we should merge this PR, and accept some upgrading/downgrading. Change-Id: I57739777ab3d86fa7e0375834cf9140e8e6ac984 Signed-off-by: Jes B. Klinke <[email protected]> (cherry picked from commit 2667a3a)
jesultra
force-pushed
the
hyperdebug_firmware
branch
from
0a4091d to
77bbccb
Compare
Support 48Mhz clock generation, and bugfixes Add ability to change HyperDebug core clock frequency. Choosing 96 MHz will allow any PWM capable pin to produce a 48 MHz clock suitable for driving a NuvoTitan chip. (CN10.31 is the only pin that can output 96 MHz.) Also included are a few bugfixes to HyperDebug polling the "GSC ready" signal when passing through TPM operations. Relevant CLs: d090a07063 chip/stm32: Avoid stuck UART to USB forwarding b3c959b5c5 board/hyperdebug: Avoid clobbering CCR_CFGR register 765b8a9d2b chip/stm32: Wait for core voltage to stabilize on STM32L4/5 6e9f274d2c board/hyperdebug: Improve GSC ready pulse detection 843d7ee9a6 board/hyperdebug: Expect GSC ready pulse after transaction 1b9f351528 board/hyperdebug: Properly set system timer tick rate 3962928140 board/hyperdebug: Allow runtime changes to system clock 821e9349d2 chip/stm32: Consolidate clock enums e7f8842e93 chip/stm32: Rename STM32_HSE_CLOCK to CONFIG_STM32_CLOCK_HSE_HZ a8fc0258fe board/hyperdebug: Fast clock output on CN10.31 6265770002 board/hyperdebug: Add support for PWM via low power timers 195271c11d board/hyperdebug: Refactor PWM fbf583383f board/hyperdebug: Fix off-by-one and rounding errors Signed-off-by: Jes B. Klinke <[email protected]> Change-Id: I212c1a249249470601d667a72b29244f26bcd6c5
jesultra
force-pushed
the
hyperdebug_firmware
branch
from
77bbccb to
8c999f9
Compare
|
The cause of the HyperDebug crashes in CI has been identified, https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/6219337 . If the pending CI run goes well, I plan on merging this. |
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin earlgrey_es_sival
git worktree add -d .worktree/backport-25917-to-earlgrey_es_sival origin/earlgrey_es_sival
cd .worktree/backport-25917-to-earlgrey_es_sival
git switch --create backport-25917-to-earlgrey_es_sival
git cherry-pick -x 8c999f9e6d117ee717d96dd8fcec81cf2da3752c |
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin earlgrey_1.0.0
git worktree add -d .worktree/backport-25917-to-earlgrey_1.0.0 origin/earlgrey_1.0.0
cd .worktree/backport-25917-to-earlgrey_1.0.0
git switch --create backport-25917-to-earlgrey_1.0.0
git cherry-pick -x 8c999f9e6d117ee717d96dd8fcec81cf2da3752c |
github-actions
bot
added
the
Manually CherryPick
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.
Support 48Mhz clock generation, and bugfixes
Add ability to change HyperDebug core clock frequency. Choosing 96 MHz will allow any PWM capable pin to produce a 48 MHz clock suitable for driving a NuvoTitan chip. (CN10.31 is the only pin that can output 96 MHz.)
Also included are a few bugfixes to HyperDebug polling the "GSC ready" signal when passing through TPM operations.
Relevant CLs:
d090a07063 chip/stm32: Avoid stuck UART to USB forwarding
b3c959b5c5 board/hyperdebug: Avoid clobbering CCR_CFGR register
765b8a9d2b chip/stm32: Wait for core voltage to stabilize on STM32L4/5
6e9f274d2c board/hyperdebug: Improve GSC ready pulse detection
843d7ee9a6 board/hyperdebug: Expect GSC ready pulse after transaction
1b9f351528 board/hyperdebug: Properly set system timer tick rate
3962928140 board/hyperdebug: Allow runtime changes to system clock
821e9349d2 chip/stm32: Consolidate clock enums
e7f8842e93 chip/stm32: Rename STM32_HSE_CLOCK to CONFIG_STM32_CLOCK_HSE_HZ
a8fc0258fe board/hyperdebug: Fast clock output on CN10.31
6265770002 board/hyperdebug: Add support for PWM via low power timers
195271c11d board/hyperdebug: Refactor PWM
fbf583383f board/hyperdebug: Fix off-by-one and rounding errors