[DISCUSS] Extending uTVM, micro.Session and more boards

Development
#1

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?

#2

Thanks for bringing this up, this is definitely on our radar! The initial uTVM PR was intended to sync our prototype work, based on the original RFC, 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 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. 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

#3

Sounds good. Looking forward to what you end up posting.