-
Notifications
You must be signed in to change notification settings - Fork 913
Description
Description
A dependency of #27932.
Currently, QEMU does not properly model power-on-reset in the rstmgr device in a way that can support e.g. provisioning personalization flows. Specifically, the rstmgr declares its first QEMU reset event to be a POR, but then declares subsequent resets are not. However, when we currently issue a reset via the QEMU system monitor, the rstmgr is not re-realized and so it does not reset to a power-on-reset state.
This causes issues for tests that bootstrap and then rely on the rstmgr reset reason: bootstrapping triggers a software reset when complete, but it is expected that asserting and releasing the reset strapping will cause a Power-on-Reset which will re-initialize the reset reason. With the current implementation, after bootstrapping the test always thinks there has been a SW reset, even on the first run.
To fix this, we need to figure out why the QEMU monitor system-reset does not reinitialize and update the QEMU model to handle this case. If this is not possible, an alternative might be modelling the POR pad/straps as a CharDev on the QEMU Earlgrey machine itself / a padring and then using that to implement resetting instead (this would more closely match the hardware, but would not allow QEMU system resets to be used directly, which is not ideal - ideally, both would be supported).