gromero commented on a change in pull request #8613: URL: https://github.com/apache/tvm/pull/8613#discussion_r688985129
########## File path: apps/microtvm/reference-vm/README.md ########## @@ -15,53 +15,86 @@ <!--- specific language governing permissions and limitations --> <!--- under the License. --> -# microTVM Reference Virtual Machines +# microTVM Reference Virtual Machines (RVM) -This directory contains Vagrant specifications that create reference Virtual Machines for use with -microTVM. These machines help microTVM users collaborate by providing a stable reference test -environment. +This directory contains Vagrant specifications that create Reference Virtual +Machines (RVM) for use with microTVM. These machines help microTVM users +collaborate by providing a stable reference environment to build and test +microTVM. -For more information on how to use them, see the microTVM Reference Virtual Machines tutorial. +For more information on how to use them, see the +[microTVM Reference VM tutorial](../../../tutorials/micro/micro_reference_vm.py). -## Reference VM Developer Information +## microTVM Developer Information -Each RTOS or platform that integrates with microTVM can check-in a Reference VM in this directory to -help the community collaborate. You should use the tools provided here to ensure a uniform release -process across all platforms. Typically, releases need to be created by TVM committers. +Each RTOS or platform (like Zephyr, FreeRTOS, etc) that integrates with microTVM +can check-in a Reference VM in this directory to help the community collaborate. +You should use the tools provided here to ensure a uniform release process +across all platforms. Typically, releases need to be created by TVM committers. -Generally speaking, it's expected that any integrated platform with a regression test checked-in to -the tvm repository should also define a reference VM. If you want to integrate a new platform, -please raise a discussion on [the forum](https://discuss.tvm.ai). +Generally speaking, it's expected that any integrated platform with a regression +test checked-in to the tvm repository should also define a reference VM. If you +want to integrate a new platform, please raise a discussion on +[the forum](https://discuss.tvm.ai). -### Organization -Reference VMs are organized as follows: +## Reference VMs Organization + +Reference VMs are organized in this directory as follows: + +``` +. ++-- base-box-tool.py - Reference VM build, test, and release tool. ++-- <platform>/ - One or more dirs related to the supported platform(s). + +-- Vagrantfile - Vagrantfile that end-users will invoke. Should be based + | off a base box which contains dependencies other than the + | TVM python dependencies. + +-- base-box/ - Top-level directory which defines the base box. + +-- Vagrantfile.packer-template - 'packer' template Vagrantfile which + | will be used to build the base box. + +-- test-config.json - JSON file explaining how to perform + release tests to base-box-tool.py. +``` -* `base-box-tool.py` - Reference VM build, test, and release tool -* `<platform>/` -** `Vagrantfile` Vagrantfile that end-users will inovke. Should be based off a base box - which contains dependencies other than the TVM python dependencies. -** `base-box` - Top-level directory which defines the base box. -*** `Vagrantfile.packer-template` - Packer template Vagrantfile which will be used to build the - base box. -*** `test-config.json` - JSON file explaining how to perform release tests to `base-box-tool.py` ## Creating Releases -1. Build the base box for the given platform: `$ ./base-box-tool.py [--provider=<provider>] build <platform>` -2. Run release tests for each platform: - 1. Connect any needed hardware to the VM host machine. - 2. Run tests: `$ ./base-box-tool.py [--provider=<provider>] test [--microtvm-platform=<platform>] <platform> [--test-device-serial=<serial>]`. This - command does the following for each provider: - 1. Copies all files inside `./<platform>` except `.vagrant` and `base-box` to - `./release-test`. This is done to avoid reusing any VM the developer may have started. - 2. Executes `$ vagrant up [--provider=<provider>]`. - 3. Finds an attached USB device matching the VID and PID specified in `test-config.json`, - and if `--test-device-serial` was given, that serial number (as reported to USB). Creates - a rule to autoconnect this device to the VM, and also attaches it to the VM> - 4. SSHs to the VM, `cd` to the TVM root directory, and runs `test_cmd` from - `test-config.json`. Nonzero status means failure. -3. If release tests fail, fix them and restart from step 1. -4. If release tests pass: `$ ./base-box-tool.py [--provider=<provider>] release <--release-version=<version>> <--platform-version=<version>> <platform>`. Be sure you've logged - in to Vagrant Cloud using the `vagrant` tool. +1. **Build** the base box for a given platform: +```bash +$ ./base-box-tool.py [--provider=<provider>] build <platform> +``` + +2. **Run** release tests for each platform: + + A. Connect any needed hardware to the VM host machine; + + B. Run tests: + ```bash + $ ./base-box-tool.py [--provider=<provider>] test [--microtvm-platform=<platform>] [--test-device-serial=<serial>] <platform> Review comment: I totally agree, 'platform' is ambiguous in that context. 'platform' is a term very often (ab)used imho : ) So, roughly speaking, `PLATFORM` is what TVM consider as a platform for microTVM, like `zephyr` and `arduino`, while `MICROTVM_PLATFORM` is what a platform is for `zephyr` and `arduino`, so usually maps to a board name, like `stm32f746xx_disco` for `zephyr`. I have added a concrete example for 'build' and 'test' commands to v2 (https://github.com/apache/tvm/pull/8613/commits/499427b720796641fabfe26eba792e6dac335e7e). I hope it helps also to avoid the ambiguity. In fact in v1 I added a mention to Zephyr and FreeRTOS as example for PLATFORM but haven't expanded on MICROTVM_PLATFORM ... On v2 I've replaced `FreeRTOS` example by `Arduino` since PR https://github.com/apache/tvm/pull/8748 is being cooked. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
