Merge pull request #1980 from tock/opentitan-notes-2020-06

doc: ot: notes: June meetings

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

@@ -0,0 +1,74 @@
+# 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.

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

@@ -0,0 +1,65 @@
+# Tock OT Notes 6/18/2020
+
+Present:
+- Brad Campbell (Chair), University of Virginia
+- Johnathan Van Why, Google
+- Phil Levis, Stanford
+- Alphan Ulusoy, Google
+- Garret Kelly, Google
+- Vadim Sukhomlinov, Google
+- Alistair Francis, Western Digital
+- Silvestrs Timofejevs, lowRISC
+- Andrey Pronin, Google
+
+## Updates
+
+- Alphan: Debug PR for processes needs to be updated.
+
+- Phil: Resuming work on timer HIL updates.
+
+- Johnathan: Working on a size analysis for libtock-rs with size printing for
+  each example. Using compiler flags to optimize for size seems to make binaries
+  _larger_.
+
+- Brad: libtock-c RISC-V merged. Need to run `make RISC-V=1`.
+- CDC support for USB working.
+
+- Phil: Working on a Tock 2.0 concrete plan. Then can hopefully implement
+  changes quickly.
+
+## 64 bit Timers
+
+- Phil: Timers in Tock generally 32 bits, RISC-V uses a 64 bit counter.
+- New timer re-design should easily support 64 bits in the kernel. There are no
+  dependencies on bit width of frequency.
+- The userspace API is 32 bits, however. Should there be a 64 bit version in
+  addition? I'm imagining using allow to share the large values.
+- Alistair: Why not use 64 bit return values instead of shared buffer?
+- Phil: If we move to 64 bit return values, then there is no room to return the
+  value _and_ an error code.
+- Alistair: Is there a specific use case for 64 bit timers right now?
+- Phil: No, for now this would just be a nice to have. Looking for
+  thoughts/feedback.
+- Alistair: Could add it later?
+- Phil: Sure.
+- Johnathan: I'm in favor, reduce code duplication between kernel and userspace,
+  plus less wrapping.
+- Vadim: What precision or frequency?
+- Phil: Good question. In-kernel not specified, helper functions to convert
+  between common values.
+- Not clear what should be presented to userspace.
+- Vadim: Would want to avoid long division and expensive conversion between time
+  domains. Want something that would be generally used.
+- Phil: Makes sense. I do want to avoid userspace having to probe what the
+  kernel supports.
+- Vadim: Definitely somewhat app specific.
+- Phil: Users base 10, computers base 2.
+- Vadim: Could have a syscall to retrieve a good conversion value that makes any
+  conversions efficient.
+- Phil: Yeah if you have a weird conversion factor it could be hardcoded in
+  userspace or the kernel.
+- Johnathan: Or pass mask and shift to avoid division.
+- Brad: I think it is good to expose the hardware capabilities to userspace. I
+  expect that people on RISC-V will expect to have a 64 bit timer. But, want
+  things to be easy still. Userpsace libraries can help hide this.
+- Phil: Yeah, but will need different syscalls for 64 bit.