Add support for the ibex-super-system

[beezow]

Adds chip and demo apps for the ibex super system. This is needed for testing on the FPGA.

[beezow]

I should have made this as a draft. It still needs some cleanup and requires #41.

[beezow]

The test suite is not included as it will not pass. When running the unaligned instruction test, it will hang the core.

[furquan-rivos]

The test suite is not included as it will not pass. When running the unaligned instruction test, it will hang the core.

Why is that? Shouldn't it be caught by the M-mode kernel and not result in a hang?

[beezow]

The test suite is not included as it will not pass. When running the unaligned instruction test, it will hang the core.

Why is that? Shouldn't it be caught by the M-mode kernel and not result in a hang?

The exception never gets thrown. Jumping to the aligned address on either side generates an illegal instruction, but the unaligned case just hangs. Attempting to r/w from the same address also generates the correct exceptions.

[furquan-rivos]

Where does this value come from?

[beezow]

I just made it up, any values much smaller and it interrupts so fast the core cannot do anything. I tried to calculate the correct value based on the FPGA clock, but that was absurdly slow. I think I was missing something about what clock frequency the FPGA was actually running at.

[furquan-rivos]

Probably add a comment or a bug to follow-up on this if you plan to push this in as is?

[furquan-rivos]

The test suite is not included as it will not pass. When running the unaligned instruction test, it will hang the core.

Why is that? Shouldn't it be caught by the M-mode kernel and not result in a hang?

The exception never gets thrown. Jumping to the aligned address on either side generates an illegal instruction, but the unaligned case just hangs. Attempting to r/w from the same address also generates the correct exceptions.

Is that a known bug with the system? As per the priv spec, this should throw an "instruction address misaligned" exception. What test is this exactly that fails?

Also, does this help:

diff --git a/sys/kern/src/arch/riscv32.rs b/sys/kern/src/arch/riscv32.rs
index ebe22e99..b68d405d 100644
--- a/sys/kern/src/arch/riscv32.rs
+++ b/sys/kern/src/arch/riscv32.rs
@@ -571,6 +571,9 @@ fn trap_handler(task: &mut task::Task) {
         Trap::Exception(Exception::IllegalInstruction) => unsafe {
             handle_fault(task, FaultInfo::IllegalInstruction);
         },
+        Trap::Exception(Exception::InstructionMisaligned) => unsafe {
+            handle_fault(task, FaultInfo::IllegalInstruction);
+        },
         Trap::Exception(Exception::LoadFault)
         | Trap::Exception(Exception::StoreFault) => unsafe {
             handle_fault(

[beezow]

The test suite is not included as it will not pass. When running the unaligned instruction test, it will hang the core.

Why is that? Shouldn't it be caught by the M-mode kernel and not result in a hang?

The exception never gets thrown. Jumping to the aligned address on either side generates an illegal instruction, but the unaligned case just hangs. Attempting to r/w from the same address also generates the correct exceptions.

Is that a known bug with the system? As per the priv spec, this should throw an "instruction address misaligned" exception. What test is this exactly that fails?

Also, does this help:

diff --git a/sys/kern/src/arch/riscv32.rs b/sys/kern/src/arch/riscv32.rs
index ebe22e99..b68d405d 100644
--- a/sys/kern/src/arch/riscv32.rs
+++ b/sys/kern/src/arch/riscv32.rs
@@ -571,6 +571,9 @@ fn trap_handler(task: &mut task::Task) {
         Trap::Exception(Exception::IllegalInstruction) => unsafe {
             handle_fault(task, FaultInfo::IllegalInstruction);
         },
+        Trap::Exception(Exception::InstructionMisaligned) => unsafe {
+            handle_fault(task, FaultInfo::IllegalInstruction);
+        },
         Trap::Exception(Exception::LoadFault)
         | Trap::Exception(Exception::StoreFault) => unsafe {
             handle_fault(

That will not help, the trap handler never gets called. Even re flashing hubris does not help (which initiates a reset), I have to fully power cycle the FPGA. The actual test cause is test_fault_nullexec within test-suite, but that translates to a badexec within the test-runner, which attempts to execute at address 0x1. I am adding some details to https://rivosinc.atlassian.net/browse/SW-205