Conversation
|
@ppannuto How should we move forward on this? Are you still planning on doing some more testing, should someone else do that, or should we just merge? I'm happy to offer testing on the RISC-V side. |
|
I believe that @tyler-potyondy and @vrindisbacher tested this fairly extensively working on #4384. I think this is probably just good to merge. |
|
@tyler-potyondy @vrindisbacher Did you also test this on RISC-V? |
|
I didn't test on RISC-V but I have been working on verifying the RISC-V implementation. I already verified the allocate app memory region method and it seems free of bugs. |
|
Cool, that's good to hear 😅. I'll put it on my todo list to run this app on RISC-V, just to make sure we won't be surprised later if the test app itself somehow was incorrect. |
|
@vrindisbacher @ppannuto This seems to almost work on RISC-V, apart from one error that I believe should also affect Cortex-M. Fix and discussion thread for that in #535. |
Untested.
Inspired by the recent MPU configuration bug, here is a MPU test that is 'bare metal', i.e. would not be saved by the implicit
sbrkin Tock's libc startup. Note, that this specific test would not actually catch the issue — this currently provides coverage of everything that the app should access without fault. But the goal is to provide complete coverage of the 'good cases' and be easy to modify for specific test cases.