You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tvm.apache.org by Tom Gall via TVM Discuss <no...@discuss.tvm.ai> on 2020/05/11 20:14:17 UTC
[TVM Discuss] [Development] [DISCUSS] Extending uTVM, micro.Session
and more boards
Hi Everyone (especially fellow uTVM fans)
I've been looking at micro.device.arm.*, micro.Session and related code like openocd_low_level_device.cc in src/runtime/micro.
At first blush I feel like we should be looking at other means to drive a session besides perhaps OpenOCD especially when I see code like:
python/tvm/micro/device/arm/stm32f746xx.py
BASE_ADDR = 0x20000000
AVAILABLE_MEM = 320000
DEFAULT_SECTION_CONSTRAINTS = {
"text": (18000, MemConstraint.ABSOLUTE_BYTES),
"rodata": (100, MemConstraint.ABSOLUTE_BYTES),
"data": (100, MemConstraint.ABSOLUTE_BYTES),
"bss": (600, MemConstraint.ABSOLUTE_BYTES),
"args": (4096, MemConstraint.ABSOLUTE_BYTES),
"heap": (100.0, MemConstraint.WEIGHT),
"workspace": (64000, MemConstraint.ABSOLUTE_BYTES),
"stack": (32, MemConstraint.ABSOLUTE_BYTES),
}
Shouldn't OpenOCD, or pyOCD be the ultimate holder of board specific data instead of having to result in hard coded python that is specific to a Microcontroller board? I'd like to think those projects generally have this board info. A future filled with many different files for some population of boards being kept and maintained in TVM doesn't seem like a good idea.
Any one else thinking about this?
---
[Visit Topic](https://discuss.tvm.ai/t/discuss-extending-utvm-micro-session-and-more-boards/6643/1) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/fdf7b21208081cf34321bc0c73feb63fb4045f205e4bf2e2a7cc0c89977d5a10).
[TVM Discuss] [Development] [DISCUSS] Extending uTVM, micro.Session
and more boards
Posted by Tom Gall via TVM Discuss <no...@discuss.tvm.ai>.
Sounds good. Looking forward to what you end up posting.
---
[Visit Topic](https://discuss.tvm.ai/t/discuss-extending-utvm-micro-session-and-more-boards/6643/3) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/a61cf3b37621bf06e25ea797385dc04b1b0588e3adb0966d0609f413c50295c2).
[TVM Discuss] [Development] [DISCUSS] Extending uTVM, micro.Session
and more boards
Posted by Andrew Reusch via TVM Discuss <no...@discuss.tvm.ai>.
Thanks for bringing this up, this is definitely on our radar! The initial [uTVM PR](https://github.com/apache/incubator-tvm/pull/5417) was intended to sync our prototype work, based on the [original RFC](https://github.com/apache/incubator-tvm/issues/2563), up to master. We'll have some initial results evaluating the prototype forthcoming soon.
At the same time, we realize that needing to hardcode lots of device specific things, such as the memory layout you've included here, won't scale as we expand. To that end, Tianqi submitted a [major refactor](https://github.com/apache/incubator-tvm/pull/5484) the TVM RPC subsystem. This refactor lays the groundwork to implement a TVM RPC server without the use of dynamic linking. You can see an example of that with the [Web Assembly PR](https://github.com/apache/incubator-tvm/pull/5506). We're planning to take a similar approach with µTVM, with a lot more flexibility in terms of compilation, linking, and the RPC transport layer. We should be posting a more detailed RFC this week.
I'm curious if that approach roughly aligns with your use case? I think it would be better to save discussion on implementation details for the forthcoming RFC, but happy to continue discussing at a high level on this thread.
-Andrew
---
[Visit Topic](https://discuss.tvm.ai/t/discuss-extending-utvm-micro-session-and-more-boards/6643/2) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/759c63143668d9394a49c6caccac03b3d7092fd26fdf264c60cafa7c9a0dfba6).