Repository navigation
[sw-sysemu] Model MRAM power-on SW visible effects - #122
Draft
AFOliveira wants to merge 4 commits into
Draft
AFOliveira wants to merge 4 commits into
AFOliveira wants to merge 4 commits into
Conversation
AFOliveira
requested review from
glguida and
vidas
and removed request for
glguida
April 1, 2026 15:37
Model bridge_status_reg (mram_ready from dsleep state), slverr_status_reg (clear-on-read sticky bits), and arbiter_mode_reg with proper register semantics.
MRAM starts unpowered. The mram_dsleep_en register bit resets to 0 (matching TRM) but MRAM only powers on when software first writes to PowerDomainReq with mram_dsleep_en=0. From that point on, writing 1 puts MRAM back to sleep and 0 wakes it. Accesses to MRAM while asleep set the slverr sticky bits (mram_not_ready + mram_unpowered) and raise an access fault.
Clear mram_dsleep_en in PowerDomainReq before jumping to MRAM.
mram_dsleep_fault: load from MRAM while asleep triggers access fault mram_dsleep_wake: sleep/wake cycle, verify bridge_status and MRAM access
AFOliveira
force-pushed
the
feat/erbium-mram-dsleep
branch
from
April 3, 2026 08:55
a394607 to
f8221ca
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Replace the mram_registers DenseRegion with a MramBridgeEr device that
models bridge_status_reg (mram_ready from live dsleep state query),
slverr_status_reg (clear-on-read sticky bits), and arbiter_mode_reg.
MRAM now starts in deep sleep (mram_dsleep_en=1 in PowerDomainReq),
matching hardware reset state. Accesses to MRAM while asleep set the
slverr sticky bits (mram_not_ready + mram_unpowered) and fault.
Software clears mram_dsleep_en to wake MRAM — bridge_status_reg.mram_ready
then immediately reads 0xF.
Test boot.S updated to clear mram_dsleep_en before jumping to MRAM.
I've set this as a draft PR as we need #119 to be sent first, so we can bring up MRAM behavior in that flow, so users can rely on that flag to be behaviourly similar to Boot ROM.