# U54 core on Arty 7 & S MODE

**URL:** <https://forums.sifive.com/t/u54-core-on-arty-7-s-mode/2986>\
**Category:** RISC-V\
**Created:** [October 30, 2019, 7:49am UTC](https://forums.sifive.com/t/u54-core-on-arty-7-s-mode/2986 "2019-10-30T07:49:26Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![fkt87423](https://avatars.discourse-cdn.com/v4/letter/f/6a8cbe/32.png) [@fkt87423](https://forums.sifive.com/u/fkt87423)\
**Post date:** [October 30, 2019, 7:49am UTC](https://forums.sifive.com/t/u54-core-on-arty-7-s-mode/2986/1 "2019-10-30T07:49:26Z")

</div>

Hi All,

I’m developing a own OS on arty 7 100T with the bitstream from sifive\_coreip\_U54\_AXI4\_rtl\_eval\_v19\_08p0p1.  
I’ve ran in a problem I have no idea yet how to debug. When switching from machine mode to system mode the core generates a Instruction Fault exception(mcause = 1) I tried the opensbi in a similar setup but the result seems to be the same, after I setup mepc & mstatus for the S mode, I execute a mreturn to the system start code but the it always generates a access fault on the first instruction. This happens with the MMU on or off.

For whatever is worth the qemu with machine set to sifive\_u works fine.

Considering that I’m a newbie in RISCV I assume I’m not setting up something properly but I have no idea what that might be? Does anybody have any insight?

Thanks

---

<div class="post-metadata">

**Author:** ![fkt87423](https://avatars.discourse-cdn.com/v4/letter/f/6a8cbe/32.png) [@fkt87423](https://forums.sifive.com/u/fkt87423)\
**Post date:** [October 30, 2019, 10:08am UTC](https://forums.sifive.com/t/u54-core-on-arty-7-s-mode/2986/2 "2019-10-30T10:08:29Z")

</div>

To answer my own question it, while the RISCv specs don’t mention it explicitly - if the PMP is present it must be configured. Since M mode ignores the PMP protections my situation made sense.

qemu doesn’t implement this behaviour.

---

<div class="post-metadata">

**Author:** ![bruce](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.sifive.com/bruce/32/452_2.png) [@bruce](https://forums.sifive.com/u/bruce)\
**Post date:** [October 30, 2019, 12:26pm UTC](https://forums.sifive.com/t/u54-core-on-arty-7-s-mode/2986/3 "2019-10-30T12:26:00Z")

</div>

Yes, if no entry is found in the PMP for an address then machine mode = ok, any other mode = access fault.

M mode doesn’t exactly ignore the PMP as you can explicitly lock off an address range even from M mode (until full reset).

I’m not sure, but I think qemu may be taking a shortcut and pretending you don’t have a PMP if you did nothing to configure it.

---

<div class="post-metadata">

**Author:** ![fkt87423](https://avatars.discourse-cdn.com/v4/letter/f/6a8cbe/32.png) [@fkt87423](https://forums.sifive.com/u/fkt87423)\
**Post date:** [October 30, 2019, 1:07pm UTC](https://forums.sifive.com/t/u54-core-on-arty-7-s-mode/2986/4 "2019-10-30T13:07:49Z")

</div>

Thanks for the confirmation. One more issue I’ve encountered: the VM seems to work, I can read and execute code but the first store my OS does to stack it generates a fault, however the scause = 0xF. I don’t see this documented anywhere. Is this a SiFive specific cause?

---

<div class="post-metadata">

**Author:** ![fkt87423](https://avatars.discourse-cdn.com/v4/letter/f/6a8cbe/32.png) [@fkt87423](https://forums.sifive.com/u/fkt87423)\
**Post date:** [October 30, 2019, 1:25pm UTC](https://forums.sifive.com/t/u54-core-on-arty-7-s-mode/2986/5 "2019-10-30T13:25:29Z")

</div>

Again answering my question(doh) I was reading the wrong RISCv priv isa document. 0xf is exactly a store/AMO page fault.