[manuf,qemu] Provisioning flow fixes for QEMU #28898
Open
+20
−9
Conversation
This file contains hidden or 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
When sending the final hash of all personalization objects to the host to confirm the integrity of provisioning, the current implementation manually toggles the GPIO TX Ready indicator used with the SPI console for the transmission to high before the transmission, and low after. In reality, the ujson serialization of the hash will call through to the OTTF SPI console via `base_print` which will handle all of the logic for toggling the pin for you when the data is ready in the SPI read buffer. The current logic in fact makes timing assumptions: it assumes that the data will be ready in the SPI read buffer by the time the host tries to read the frame header based on the GPIO pin going high . This works now because silicon & FPGAs are fast enough, but might not be true if the SPI console becomes more complicated / slower, or at different clock speeds, or in sim/emulation environments (e.g. QEMU, which does not synchronize I/O and guest SW well, sometimes errors on this case). The fix is simple: let the SPI console handle the GPIO pin for us, and stop trying to manually handle it ourselves. Signed-off-by: Alex Jones <[email protected]>
AlexJones0
requested review from
cfrantz,
jwnrt,
pamaury and
timothytrippel
and removed request for
a team
pamaury
approved these changes
Dec 9, 2025
Contributor
pamaury
left a comment
pamaury
left a comment
There was a problem hiding this comment.
The change looks good to me, though I don't have all the context of the provisioning flow to really understand everything.
jwnrt
approved these changes
Dec 9, 2025
See the relevant comments. Only changes the provisioning code path for the QEMU case, to handle assumptions already built in for FPGAs. Signed-off-by: Alex Jones <[email protected]>
AlexJones0
force-pushed
the
qemu_manuf_fixes
branch
from
215a7e2 to
7211133
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
This PR makes the minimal necessary changes to the provisioning flow to provide the support required to be able to run the end-to-end orchestrator tests in QEMU, to emulate provisioning flows. The 1st commit resolves a bug that does not cause a problem on FPGA/silicon but does start to cause issues on QEMU, and the 2nd adds special case handling for reading uninitialized flash on QEMU (different to FPGA). See the commit messages and comments for more details.
Aside: to be able to build the orchestrator zip for QEMU we will need to have signed
ft_personalize_sivalandrom_ext_dice_x509_prodbinaries present in the repo (currently exist only for silicon & FPGAs). I would assume for non-silicon environments these are generated and signed with fake keys, but I cannot find any documentation on how these are produced for non-silicon environments. It also isn't clear to me what online/manual intervention is required to run the E2E orchestrator tests for the SiVal SKU (or whether this is even possible for me to perform locally / for QEMU). I can't find any supporting documentation for these tests aside from some guidance for running the orchestrator. Any more information / suggestions would be appreciated.