ContextQMD
Back to Tock

Tock OT Notes 6/11/2020

doc/wg/opentitan/notes/2020-06-11.md

latest3.5 KB
Original Source

Tock OT Notes 6/11/2020

Present:

  • Brad Campbell (Chair), University of Virginia
  • Steve Barber, Google
  • Alistair Francis, Western Digital
  • Johnathan Van Why, Google
  • Jon Flatley, Google
  • Silvestrs Timofejevs, lowRISC
  • Garret Kelly, Google
  • Alphan Ulusoy, Google
  • Andrey Pronin, Google

Updates

  • Johnathan: Working on external assembly to work towards libtock-rs on stable. However, new asm!() happened at the same time. Not particularly easy to use external assembly files, might be better to switch to new asm!().

  • New asm!() is a rust-specific syntax whereas before it was LLVM-specific. The issue is Rust can't guarantee it will be stable when just passing it to LLVM.

  • Alphan: Configure MPU PR only if needed merged!

  • Brad: Progress on linking RISC-V apps for multiple addresses, and then letting Tockloader select the best option.

MMIO Testing

  • Steve: We want to be able to test drivers in isolation, but these of course normally use MMIO, which is hardware-dependent. We would like to be able to run unit tests.
  • Tock uses StaticRef for handles to MMIO registers.
  • Johnathan: There is a potential undefined behavior in general here since there is a reference to the memory, which LLVM can do a read on.
  • Steve: Idea 1: Do an "MMIO swap" using cargo features to replace the register library in the driver from the real MMIO implementation to one that allows for software emulating the hardware. Should be pretty straightforward to implement. Cargo features a little clunky, but otherwise minimal disruption to the code base.
  • Brad: Should be doable, and we have removed all VolatileCell, so we are entirely using the tock-register library.
  • Steve: Downside: have to keep global MMIO state to simulate hardware.
  • Steve: Example of a simple MMIO register implementation.
  • Steve: Idea 2: make registers a trait, and do dynamic dispatch to choose which implementation of the trait to use: one that accesses hardware or the emulated one for testing.
  • Choosing real or fake registers would be an argument.
  • Steve: Idea 3: Or could use conditional compilation in the drivers.
  • Brad: What do you think is the best option?
  • Steve: Using Rust type and traits is compelling. They could be more expressive and would permit more features and checking.
  • We have an existing implementation which demonstrates some features, but might not be a good fit in this case.
  • Global memory and cfg would work well, and is probably the best option (idea 1).
  • Brad: One of the intentional designs of StaticRef is that creating it requires an unsafe block since mapping the memory address to pointers is fundamentally unsafe.
  • Brad: We also already have the RISC-V CSR implementation of tock-reg, so we are already using the same framework with different implementations.
  • Brad: Any wide-scale changes (like to a register trait) would be a major undertaking.
  • Steve: Yeah, having multiple interfaces and options wouldn't be great.
  • Brad: How difficult is it to write the MMIO interface code...do bugs show up there?
  • Steve: That might be difficult, and I've been wondering about using Rust types to help make it easier.
  • Garret: Using types is interesting, but does seem difficult.
  • Steve: I think it can be done, but may need procedural macros to make it ergonomic.
  • Brad: This seems like a promising direction for testing. I suggest opening a tracking issue or sending a tock-dev email just to get it on people's radar. Merging goes much smoother if ideas aren't presented first in a PR.