Arm backend: implement EthosUBackend::is_available() hardware check

[vacu9708]

Summary

EthosUBackend::is_available() returned 1 unconditionally. Method::load() calls is_available() before init() and returns Error::NotFound with a clear message when the backend is unavailable — but that check was never triggered.

The consequence differs by platform:

• Cortex-M (baremetal): ethosu_init() must be called by the firmware before ExecuTorch runs — it registers the NPU driver handle that ethosu_reserve_driver() later waits for. If it goes missing for some reason, the program hangs silently inside ethosu_reserve_driver() which waits forever on a semaphore. No error is returned, no log is produced, and the device appears frozen.
• Cortex-A (Linux): the device file /dev/ethosu0 may be absent if the kernel module is not loaded. the error was logged but attributed to the driver invocation rather than to availability.

flowchart LR
    subgraph before["Before - is_available() = return 1"]
        direction TB
        B1["Method::load()"]
        B2["is_available()\nunconditionally returns true"]
        B3["init()\nexecute()"]
        B4["ethosu_reserve_driver()"]
        B5["invoke_linux_driver()\n-> cryptic driver error\nfails late"]
        SEM(["Semaphore count = 0\n==\nethosu_init() never called"])

        B1 --> B2 --> B3
        B3 -- Cortex-M --> B4
        B3 -- Cortex-A --> B5
        B4 -->|semaphore_take\nWAIT_FOREVER| SEM
        SEM -->|"🔄 spinning forever\nno error / no log"| SEM
    end

    subgraph after["After - is_available() checks hardware"]
        direction TB
        A1["Method::load()"]
        A2{"is_available()"}
        A3["ethosu_driver_is_registered()\nregistered_drivers == NULL"]
        A4["EthosU::Device('/dev/ethosu0')\nthrows if absent"]
        A5["Error::NotFound\n early / clear message"]

        A1 --> A2
        A2 -- Cortex-M --> A3
        A2 -- Cortex-A --> A4
        A3 -- false --> A5
        A4 -- throws --> A5
    end

    before ~~~ after

Loading

Changes

• Cortex-M — adds ethosu_driver_is_registered() to ethos-u-core-driver. It checks registered_drivers != NULL — and answers "was ethosu_init() called?" The semaphore count is always > 0 when registered_drivers != NULL, so a true return guarantees ethosu_reserve_driver() will not block.
• Cortex-A — probes the default device path by constructing EthosU::Device, which throws if the device is absent or unopenable.

File	Change
EthosUBackend_Internal.h	Declare platform_is_available()
EthosUBackend.cpp	Replace "TODO" with actual implementation
EthosUBackend_Cortex_M.cpp	Implement via ethosu_driver_is_registered(); weak symbol fallback (return true) for build paths where the patch is not applied
EthosUBackend_Cortex_A.cpp	Implement via EthosU::Device probe
corstone_utils.cmake	Add patch_repo call for core_software/core_driver (Corstone SDK)
examples/arm/ethos-u-setup/core_driver/0001-Add-ethosu_driver_is_registered.patch	Add ethosu_driver_is_registered() to the driver; applied to both the Corstone SDK and Zephyr hal_ethos_u
zephyr/CMakeLists.txt	Apply the patch to hal_ethos_u at CMake configure time

ethosu_driver_is_registered() is added via a patch file rather than an upstream contribution because ExecuTorch already uses this mechanism for the Ethos-U SDK. This PR extends the same pattern to core_driver.
The weak symbol ensures any other build path not reached by the patch degrades to return true rather than failing at link time.

Tests

No tests added. Other backends like VGFBackend, XNNPACK, and MLX each have real is_available() implementations and were merged without tests.
The implementations here are similarly straightforward; I think end-to-end coverage would require disproportionate infrastructure for changes of this size.

$ lintrunner backends/arm/runtime/EthosUBackend*.cpp \
             backends/arm/runtime/EthosUBackend_Internal.h \
             backends/arm/scripts/corstone_utils.cmake
ok No lint issues.

cc @digantdesai @freddan80 @per @zingo @oscarandersson8218 @mansnils @Sebastian-Larsson @robell @rascani

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/20021

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

⚠️ 11 Awaiting Approval, 2 Unrelated Failures

As of commit 63879e9 with merge base 3f0e901 ():

AWAITING APPROVAL - The following workflows need approval before CI can run:

• Build documentation (gh)
• Build Presets (gh)
• Cadence Build & Test (gh)
• Lint (gh)
• periodic (gh)
• Test ARM Backend (gh)
• Test CoreML Backend (gh)
• Test QNN Backend (gh)
• Test Vulkan Backend (gh)
• Test WebGPU Backend (gh)
• Test XNNPACK Backend (gh)

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• trunk / test-arm-backend-ethos-u (test_smaller_stories_llama_tosa) / linux-job (gh) (trunk failure)
  ##[error]The operation was canceled.
• trunk / test-arm-backend-vkml (test_smaller_stories_llama_vkml) / linux-job (gh) (trunk failure)
  ##[error]The operation was canceled.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[pytorch-bot]

Workflows were awaiting approval. CI has now been triggered for the ciflow labels on this PR.

[vacu9708]

I don't seem to have merge permission. Could a maintainer please merge this once there are no remaining blockers?

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[zingo]

Nice, thanks!
I enabled deeper testing lets see that tests pass before merging :)

[vacu9708]

CI failures : test-arm-backend-zephyr raises undefined reference to ethosu_driver_is_registered

• Fixed it by applying the patch(ethosu_driver_is_registered) to the Zephyr build path too
• Added a fallback in case the patch to ethosu_driver_is_registered() is not applied
• Added a TODO : "Upstream ethosu_driver_is_registered() into the core driver and remove the weak fallback."

[zingo]

Hi thinking about it it would be good if we can either get this upstreamed or keep it outside of the git as user can have their own version of the driver supplied from the build system from the vendor. Adding A patch like this works inside the project but might collide if build in other systems like you discovered with Zephyr. I'm not sure about CMSIS-PACK (on it's way) and future integration to example PlatformIO/Arudoino might need to handle this.

[vacu9708]

Hi @zingo. I agree with you.
I removed the patch file and added a TODO comment above the weak fallback.

I am going to submit an upstream PR to add ethosu_driver_is_registered().

Once the upstream change is merged and all builds are confirmed to be using
a driver with ethosu_driver_is_registered() implemented, the weak symbol
and this TODO can be removed in a follow-up PR. Until then, the weak fallback
ensures this PR does not break any build that links against an older driver.

Without this check, ethos-u users may have a hard time debugging mysterious freezes when ethosu_init() is accidentally omitted after refactoring or for some other reason.