Skip to content
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

exercises/01 fails when run in docker against ibex #243

Closed
PhilDay-CT opened this issue Jun 11, 2024 · 8 comments
Closed

exercises/01 fails when run in docker against ibex #243

PhilDay-CT opened this issue Jun 11, 2024 · 8 comments

Comments

@PhilDay-CT
Copy link
Contributor

As noted at the Sonata Hackathon exercise/01.compartmentalisation doesn't run in the dev docker, although it does work if compiled and run on the Sonata board. I tested against the latest commit (771f2bb - Jun 3rd) in case any of the recent changes to the dev contained had fixed it, but it still fails for me.

Digging in a little the line that fails in Ibex is generating the secret in secret.cc

    secret = static_cast<int32_t>(rdcycle64());

Replacing this with, for example, makes everything run fine

    //secret = static_cast<int32_t>(rdcycle64());
    secret=666;	

Commenting out the code in secret.cc which waits for the uart (so the call to rdcycle64() is in effect the first call in the therad) also makes no difference.

Adding a compartment_error_handler() gives the error as:

JavaScript compartment: Detected PermitAccessSystemRegistersViolation(0x18).  Register PCC(0x20) contained invalid value: 0x2004ba08 (v:0 0x2004a7c0-0x2004cb40 l:0x2380 o:0x0 p: G R-cgm- X- ---)

Calling rdcycle64() in any of the examples with IBEX works fine, so I'm assuming there is some difference in the build that I'm missing, but the only thing I spotted is that exercise xmake.luna has:

option("board")
    set_default("ibex-safe-simulator")

whereas the examples use

option("board")
    set_default("sail")

I'm happy to dig further if someone can point me in the right direction.

@davidchisnall
Copy link
Collaborator

If the board is sail then they're not using the Ibex simulator, they're the instruction simulator generated from the Sail formal model.

@davidchisnall
Copy link
Collaborator

I suspect that the recent(ish) changes to the AccessSystemRegisters permissions in Ibex may have broken mcycleh access. The test suite uses mcycle but not mcycleh (it doesn't run long enough to overflow a 32-bit cycle counter. @kliuMsft, can you check?

@PhilDay-CT
Copy link
Contributor Author

If the board is sail then they're not using the Ibex simulator, they're the instruction simulator generated from the Sail formal model.

Ah, Ok thanks. I tried changing one of the examples to the ibex simulator and then doing "xmake config --sdk=/cheriot-tools/; xmake clean; xmake; xmake run" - but that didn't fail which made me think this was the wrong track. Looks like I need to "rm -rf .xmake .cache" to really get back to a clean state ?

And the exercise needs the simulator because the sail model doesn't have a uart - is that right ?

(Sorry for the questions - still feeling my way around here some)

@davidchisnall
Copy link
Collaborator

You shouldn't need it, but sometimes rm -rf .xmake build is necessary.

@davidchisnall
Copy link
Collaborator

And the exercise needs the simulator because the sail model doesn't have a uart - is that right ?

The Sail UART is output only, yes.

@davidchisnall
Copy link
Collaborator

Kunyan confirms that this is an Ibex bug. The refactoring of the PermitAccessSystemRegisters logic accidentally missed mcycleh.

@davidchisnall
Copy link
Collaborator

The dev container is updated with the fix so this should work now.

@PhilDay-CT
Copy link
Contributor Author

Yep - runs fine now, thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants