ContextQMD
Back to Tock

Tock OT Notes 6/18/2020

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

latest2.6 KB
Original Source

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.