Zephyr: Auto-export models from prj.conf#19369
Conversation
Add cmake utility for adding a build rule to run a python file that exports a pytorch model to pte. Enable using this utility for Zephyr builds and use this in the hello-executorch sample New config CONFIG_EXECUTORCH_EXPORT_PYTHON_SCRIPT to point to your model python file CONFIG_EXECUTORCH_EXPORT_PYTHON_GENERATED_OUTPUT to the output file that was generated by the script. CONFIG_EXECUTORCH_EXPORT_PYTHON_DEPENDENCIES Make it possible to add dependency files to regenerate the PTE on next build. If used thid will add cmake rules that will trigger a (re)generation of the PTE if needed when building. Signed-off-by: Zingo Andersen <Zingo.Andersen@arm.com> Change-Id: Iddebc0316933be3136aefbf28e4fa74e033a76f7
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/19369
Note: Links to docs will display an error until the docs builds have been completed. ❌ 1 New Failure, 7 Unrelated FailuresAs of commit 563b201 with merge base af90130 ( NEW FAILURE - The following job has failed:
FLAKY - The following jobs failed but were likely due to flakiness present on trunk:
BROKEN TRUNK - The following jobs failed but were present on the merge base:👉 Rebase onto the `viable/strict` branch to avoid these failures
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
There was a problem hiding this comment.
Pull request overview
This PR adds Zephyr-facing CMake/Kconfig plumbing to auto-export ExecuTorch .pte models during configuration, then updates the hello-executorch Zephyr sample to use per-board exporter scripts (Cortex-M / Ethos-U55 / Ethos-U85) and embed the generated model.
Changes:
- Introduce
CONFIG_EXECUTORCH_EXPORT_PYTHON_*Kconfig options and Zephyr CMake helpers to resolve/auto-generate the model and drive selective-op generation. - Add reusable CMake utilities for running Python-based model exporters (configure-time and build-time).
- Update the
hello-executorchsample build, docs, and model scripts to use the new auto-export flow (including CI workflow adjustments).
Reviewed changes
Copilot reviewed 17 out of 18 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| zephyr/samples/hello-executorch/src/arm_executor_runner.cpp | Adjust logging / output dumping flow and add error-path logging behavior. |
| zephyr/samples/hello-executorch/sample.yaml | Add Zephyr sample metadata/tags. |
| zephyr/samples/hello-executorch/README.md | Document auto-export Kconfig options and updated build/run flows. |
| zephyr/samples/hello-executorch/prj.conf | Configure default exporter script/output for the sample. |
| zephyr/samples/hello-executorch/models/add.py | Remove the older minimal model module format. |
| zephyr/samples/hello-executorch/models/add_cortex-m.py | Add Cortex-M exporter script producing a .pte during configure. |
| zephyr/samples/hello-executorch/models/add_ethos-u55.py | Add Ethos-U55 exporter script producing a .pte during configure. |
| zephyr/samples/hello-executorch/models/add_ethos-u85.py | Add Ethos-U85 exporter script producing a .pte during configure. |
| zephyr/samples/hello-executorch/CMakeLists.txt | Switch sample to new Zephyr model-prepare + header-generation helpers. |
| zephyr/samples/hello-executorch/boards/mps3_corstone300_fvp.conf | Select Ethos-U55 exporter/output for Corstone-300 FVP. |
| zephyr/samples/hello-executorch/boards/mps4_corstone320_fvp.conf | Select Ethos-U85 exporter/output for Corstone-320 FVP. |
| zephyr/README.md | Document Zephyr module usage and new model-export Kconfig settings. |
| zephyr/Kconfig | Add CONFIG_EXECUTORCH_EXPORT_PYTHON_* configuration symbols. |
| zephyr/ExecuTorchZephyrModel.cmake | New: resolve model path, auto-export during configure, and generate model header. |
| zephyr/CMakeLists.txt | Include the new Zephyr model helper CMake module. |
| tools/cmake/ExportModel.cmake | New: generic CMake helpers for running Python exporters at configure/build time. |
| .gitignore | Ignore Zephyr scratch directory. |
| .github/workflows/trunk.yml | Update CI to build/run with auto-export and keep a separate “prebuilt PTE” flow. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Hi @rascani and @psiddh this add the possibility to autorun lowering in zephyr making the setup quite a bit easier as the aot_arm_compiler does not need to be runned on the side by hand anymore. It also showcase the PythonAPI lowering instead of aot_arm_compiler, we (Arm) has started to think we should nugging people to that and only have aot_arm_compiler script as a convenient addon to be used in some cases as that is more the intended Executorch way and will work on other backends also. |
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
| find_file( | ||
| _et_found_export_script | ||
| NAMES "${_et_resolved_export_script}" | ||
| HINTS "${CMAKE_CURRENT_SOURCE_DIR}" "${_et_zephyr_workspace_dir}" | ||
| PATHS "" | ||
| ) |
| Optional output path that Zephyr expects the exporter script to | ||
| write. Relative paths are resolved from the sample build directory. |
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
| if(_et_has_export_script) | ||
| set(_et_resolved_export_script "${CONFIG_EXECUTORCH_EXPORT_PYTHON_SCRIPT}") | ||
| find_file( | ||
| _et_found_export_script | ||
| NAMES "${_et_resolved_export_script}" | ||
| HINTS "${CMAKE_CURRENT_SOURCE_DIR}" "${_et_zephyr_workspace_dir}" | ||
| PATHS "" | ||
| ) |
| --model_file_path=${_et_pte_file_path} | ||
| --output_path=${CMAKE_CURRENT_BINARY_DIR}/temp.yaml |
I agree with the sentiment that the aot_arm_compiler script is a convenient add-on and the Python API. One thing that stands out though, is that we wind up having to copy and paste the same block of code on every export, with certain ops preserved, the CortexMPassManager, and certain EdgeCompileConfig values. I think it would be good if we started defining ExportRecipes for the various Arm backends. Those are intended to reduce that boilerplate. |
Ohh ExportRecipe looks nice, we should defiantly do this thanks for pointing that out, I can take a stab on this, probably on top of your target for Cortex-M PR, or accounting for it, we also have a bigger cmake PR that might be nice to get in first. Do you think we should land this PR as an intermediate step in some shape of wait for a ExportRecipe version? I see the point of not flipflopping too much but it is also kind of part of the same way of working. I also think getting ExportRecipe all the way before 1.3 will not happen so that might be factored in. I happy both waiting or bring this in as I see a point in both ways. |
I think it is unlikely that we get either approach into 1.3. The branch was cut last week, so it'll need to go through cherry-pick process. IMO, it'd be better to wait for 1.4. I do like the idea of a zephyr config option for generating the PTE, but I think my big hesitation with this PR as written is winding up with an export script per hardware X model. What's the end state you want to wind up with there? If you want to move forward with this approach, I can do a proper review tomorrow (sorry for the delay here). |
| return value | ||
|
|
||
|
|
||
| def _export_cortex_m(pte_file): |
There was a problem hiding this comment.
if we are hardcoding this signature in CMake, can we write an abc which these example models extend? Or recipies as RJ suggested.
This work started as a cmake rules around aot_arm_compiler, that made it very target generc and easy to use with the zephyr build for differnt targets, but later we decided to show minimal "prefered" lowering we think make more sense for and end user e.g. it would probably be a specific python models script tailored to your own HW maybe with extra python code in it to prepare stuff. And the aot_arm_cimpiler cmake version was going in as it's own example that would be bigger example that could be more fun (was aiming for mv2 but maybe use Yolo26 now when we have mv2) The idea was also to try to avoid generic "config" lines in the script, it makes sense when building an example for many targets but in uses own setup where they tailor a HW it makes the code a bit less easy to read. At least that was the aim, thinking about it we should maybe just pick one of the Ethos-Us and not both U55/U85 to slim it down :)
As we have a bit more time now anyway, Maybe we should wait and see what happens with the ExportRecipe stuff, I see you already took a stab on it :) |
Add cmake utility for adding a build rule to run a python file that exports a pytorch model to pte.
Enable using this utility for Zephyr builds and use this in the hello-executorch sample
New config
CONFIG_EXECUTORCH_EXPORT_PYTHON_SCRIPT
to point to your model python file
CONFIG_EXECUTORCH_EXPORT_PYTHON_GENERATED_OUTPUT
to the output file that was generated by the script.
CONFIG_EXECUTORCH_EXPORT_PYTHON_DEPENDENCIES
Make it possible to add dependency files to regenerate the PTE
on next build.
If used this will add cmake rules that will trigger a (re)generation of the PTE if needed when building.
cc @digantdesai @freddan80 @per @oscarandersson8218 @mansnils @Sebastian-Larsson @robell @psiddh @AdrianLundell