build and test Rocket32 variant of LMCO HARD smoketest P1

[kiniry]

We have been asked to build and exercise a Rocket32/P1 variant of the LMCO smoketest pipeline, located in their T1-LMCO repo on gitlab-ext. @dhand-galois was in the call so understands what is necessary for the bitstream and AFI build.

@podhrmic, we need to decide upon a mechanism for FreeRTOS to react to the illegal instruction trap that they issue when the processor detects misbehavior. Please coordinate with me and @dhand-galois on this.

[kiniry]

Dan Friedman at LMCO pointed out this thread that may be relevant: https://www.freertos.org/FreeRTOS_Support_Forum_Archive/July_2019/freertos_Software_interrupt_for_RISC-V_f6773853aej.html

[kiniry]

This quicker that we can get back to LMCO on this the better.

[kiniry]

CC @rfoot and @Abivin12 for PL visibility.

[podhrmic]

Does the LMCO processor (upon detecting an illegal instruction) put a distinct value into mcause register? If so, the easiest would be if LMCO enhanced the FreeRTOS trap handler, probably something similar to what Cambridge did for the voting system here. I am assuming that this "illegal instruction detected" is a different error than the regular illegal instruction trap as specified in RISCV specs?

[dhand-galois]

Based on what I've seen so far, they are re-using 0x2 - Illegal Instruction for their processor, but that would be a good question to them. Does FreeRTOS emulate any instructions on RISC-V? If not, then we could treat any illegal instruction exception as a possible intrusion. If it's expected that some instructions are emulated in software, we'd need to figure out some way to determine the difference.

On the HW side, I've started a P1 AFI build with their smoke test pipeline. Should be done later tonight.

[dhand-galois]

The AFI is ready for testing:

AGFI=agfi-04f1751e8a98fd53c
aws s3 cp s3://firesim-localuser/swpkgs/firesim-cloudgfe-chisel-p1-lmco-sw.tgz .

@podhrmic are you available to test FreeRTOS on it with and without the 'smoke test' sequence included? The 4 instruction sequence listed in this sample code should cause an illegal instruction example on this core (but not on a regular P1 core)

[podhrmic]

@dhand-galois I will test it today

[podhrmic]

I think it works nicely - with a non LMCO P1 I get:

[3] TX: awoken
[3] RX: received value
Blink !!!
Lanching malware sequence!
Malware sequence finished, we didn't catch it
...

And with LMCO P1 I get:

[3] TX: awoken
[3] RX: received value
Blink !!!
Lanching malware sequence!
EXCEPTION HAPPENED!
mcause: 0x2
mepc: 0xC0009800
mstatus: 0x1880

It prints the three registers (mcause, mepc, mstatus) and loops infinitely forever. Not sure what else should a handler do? If you like it, I can prettify the code and make a PR for it. This is very LMCO specific, so I am not sure if we want an LMCO branch of FreeRTOS, or just #ifdef it? @rtadros-Galois

EDIT: I will enable the exception handler that prints out registers only for CloudGFE, since on real FPGAs we have GDB that can give you the same (and more) information.

[rtadros125]

It prints the three registers (mcause, mepc, mstatus) and loops infinitely forever. Not sure what else should a handler do? If you like it, I can prettify the code and make a PR for it. This is very LMCO specific, so I am not sure if we want an LMCO branch of FreeRTOS, or just #ifdef it? @rtadros-Galois

Let's #ifdef it. Let's make it: #BIN_SOURCE_LMCO, and we have to ensure FETT-Target is defining this macro when compiling too.

[andrew-bivin]

I think it works nicely - with a non LMCO P1 I get:

[3] TX: awoken
[3] RX: received value
Blink !!!
Lanching malware sequence!
Malware sequence finished, we didn't catch it
...

And with LMCO P1 I get:

[3] TX: awoken
[3] RX: received value
Blink !!!
Lanching malware sequence!
EXCEPTION HAPPENED!
mcause: 0x2
mepc: 0xC0009800
mstatus: 0x1880

It prints the three registers (mcause, mepc, mstatus) and loops infinitely forever. Not sure what else should a handler do? If you like it, I can prettify the code and make a PR for it. This is very LMCO specific, so I am not sure if we want an LMCO branch of FreeRTOS, or just #ifdef it? @rtadros-Galois

EDIT: I will enable the exception handler that prints out registers only for CloudGFE, since on real FPGAs we have GDB that can give you the same (and more) information.

cc @LM-BrianUhlhorn @glanvild re: the above tests.

[kiniry]

As far as I understand it, we are done with this build and testing and P1 refinement is going on at LMCO. Let's close this ticket as a consequence and open up new ones if/when necessary that are more pointed.