ContextQMD
Back to Tock

Tock OT Notes 6/04/2020

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

latest2.8 KB
Original Source

Tock OT Notes 6/04/2020

Present:

  • Brad Campbell (Chair), University of Virginia
  • Jon Flatley, Google
  • Johnathan Van Why, Google
  • Alistair Francis, Western Digital
  • Phil Levis, Stanford

Updates

  • Brad: CDC working for USB on SAM4L and nRF52. Didn't require too many changes to USB drivers, so should work on OT as well.

  • Alistair: I will be getting an OT dev board with USB, so I can test there.

  • Jon: Preparing Tock host-side testing work to send out.

Loop until true or interrupt

  • Alistair: This would add a function to busy-wait on a hardware flag, while still allowing interrupts to stop the check, if the check never returns true.
  • Alistair: I think we should add this, are there outstanding questions?
  • Brad: Tock tends to avoid adding things or adding to interfaces without a demonstrator we can point to of where we need it.
  • Phil: I see the use case, but worry about generalizing. There are many cases where allowing an interrupt to continue in the middle of the check would be problematic.
  • Alistair: Part of the motivation is there are several other spin loops in Tock.
  • Phil: There really shouldn't be.
  • One issue is this could lead to callbacks executing in the middle of otherwise blocking code.
  • Alistair: As an addition to the chip trait, this wouldn't be visible everywhere.
  • Phil: Why not just wait for wfi and then handle the interrupt?
  • Alistair: It could take a while for this busy-wait to finish.
  • Phil: I have difficulty coming up with an example of where this latency would matter.
  • Alistair: Perhaps in the core kernel there could be very latency-sensitive issues.
  • Phil: But does this need to be in an interface for these cases?
  • Alistair: I was anticipating it would be more common.
  • Phil: It would be good to ask Holly, her dissertation is on this issue of managing clocks and low power modes.
  • Alistair: Ok, yeah.
  • Phil: It seems like this would be an issue in a very narrow use case, because the transition cost can't be greater than the energy savings of the low power mode.
  • Phil: And other chips, like the nRF, don't have software control of this clock switching.
  • Brad: we can also include this function in a narrow scope for now, and promote in the future as needed.

JVW

  • Johnathan: Updating libtock-rs on titan. Dependencies might be an issue.
  • Also, I have a design explorations PR under review.
  • Plus, working on an application ID proposal.
  • Brad: That will be very useful.
  • Johnathan: Have to determine if it should be setup by the board, or the kernel directly.
  • Brad: For our use cases, we need the kernel to know the app id.
  • Johnathan: Kernel would know in either case, it's more about who sets the algorithm.
  • Brad: Ah, the board could definitely make sense then. Seems like an interesting design to explore.