PMP access failure
42 views
Skip to first unread message
Bin Meng
Apr 7, 2019, 10:19:00 PM4/7/19
to RISC-V ISA Dev, RISC-V SW Dev
Hi,
In an attempt to bring up my own OS kernel, a PMP access failure was
observed and I cannot explain why it happened.
This issue was seen with running the kernel on top of OpenSBI plus
U-Boot on the SiFive Unleashed board. The same kernel boots fine on
QEMU.
I reported the issue in the OpenSBI community and the discussion did
not end up with root cause identified.
https://github.com/riscv/opensbi/issues/103
Hence I posted it here for wider audience, especially someone from
SiFive may have some ideas.
I've created a test case to demonstrate the issue using OpenSBI to
load the test payload.
https://github.com/lbmeng/opensbi/commit/f3ba28f5e56e44dad8b1d008ff244bb2b0316dff
Basically the test codes sets up a PTE to map the 2GiB memory space
with the following mapping:
0xffffffff 80000000 - 0xffffffff ffffffff (V) maps to 0x80000000 -
0xffffffff (P)
But as soon as satp is written, the core firstly traps to the stvec
address in S-mode, but fetching the first instruction at stvec address
makes the core trap to mtvec with instruction access exception code.
Per my read of the privileged spec 1.10, what the test codes does
seems not wrong.
Either the spec needs some clarification about PMP access check, or
maybe, such test happen to trigger some silicon errata?
Regards,
Bin
In an attempt to bring up my own OS kernel, a PMP access failure was
observed and I cannot explain why it happened.
This issue was seen with running the kernel on top of OpenSBI plus
U-Boot on the SiFive Unleashed board. The same kernel boots fine on
QEMU.
I reported the issue in the OpenSBI community and the discussion did
not end up with root cause identified.
https://github.com/riscv/opensbi/issues/103
Hence I posted it here for wider audience, especially someone from
SiFive may have some ideas.
I've created a test case to demonstrate the issue using OpenSBI to
load the test payload.
https://github.com/lbmeng/opensbi/commit/f3ba28f5e56e44dad8b1d008ff244bb2b0316dff
Basically the test codes sets up a PTE to map the 2GiB memory space
with the following mapping:
0xffffffff 80000000 - 0xffffffff ffffffff (V) maps to 0x80000000 -
0xffffffff (P)
But as soon as satp is written, the core firstly traps to the stvec
address in S-mode, but fetching the first instruction at stvec address
makes the core trap to mtvec with instruction access exception code.
Per my read of the privileged spec 1.10, what the test codes does
seems not wrong.
Either the spec needs some clarification about PMP access check, or
maybe, such test happen to trigger some silicon errata?
Regards,
Bin
Bin Meng
Apr 11, 2019, 6:21:07 AM4/11/19
to RISC-V ISA Dev, RISC-V SW Dev, Andrew Waterman
+Andrew
Andrew, I believe you are the right person to comment on this :)
Regards,
Bin
Regards,
Bin
Andrew Waterman
Apr 11, 2019, 3:27:40 PM4/11/19
to Bin Meng, RISC-V ISA Dev, RISC-V SW Dev
It appears to be an erratum. We currently are working to update the errata for this chip. In the mean time, if my diagnosis is right, the simple workaround is to not use gigapages with this PMP configuration.
Reply all
Reply to author
Forward
0 new messages