Merge pull request #2999 from madeline-underwood/nxp2

Nxp2 reviewed

Author: pareenaverma

content/learning-paths/embedded-and-microcontrollers/observing-ethos-u-on-nxp/1-overview.md

@@ -1,11 +1,13 @@
 ---
-title: Overview
+title: Understand ExecuTorch deployment on NXP with Ethos-U
 weight: 2
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
+## Before you begin
+
 This Learning Path assumes your FRDM i.MX 93 board is already set up and you can transfer files between your host machine and the board.
 
 If you still need to set up Linux, serial console access, and file transfer, follow the Learning Path [Linux on an NXP FRDM i.MX 93 board](/learning-paths/embedded-and-microcontrollers/linux-nxp-board/) before continuing.
@@ -19,11 +21,11 @@ The FRDM i.MX 93 platform combines:
 
 This Learning Path focuses on a concrete milestone: successful bring-up of an ExecuTorch `executor_runner` firmware on Cortex-M33 on this NXP platform.
 
-You keep the Linux side intentionally simple. Linux loads and starts the Cortex-M33 firmware through RemoteProc, and you stage a compiled ExecuTorch `.pte` model so the firmware can run it.
+This example keeps the Linux side intentionally simple. Linux loads and starts the Cortex-M33 firmware through RemoteProc, and you stage a compiled ExecuTorch `.pte` model so the firmware can run it.
 
 ## What you’ll build and validate
 
-By the end of this Learning Path, you have:
+By the end of this Learning Path, you'll have:
 
 - A `.pte` model artifact compiled for `ethos-u65-256`
 - A Cortex-M33 `executor_runner` firmware image built against prebuilt ExecuTorch libraries

content/learning-paths/embedded-and-microcontrollers/observing-ethos-u-on-nxp/10-deploy-executorchrunner-nxp-board.md

@@ -6,6 +6,8 @@ weight: 11
 layout: learningpathall
 ---
 
+## Deployment overview
+
 This section is where the heterogeneous system comes together.
 Linux on the application cores manages the lifecycle of Cortex-M33 through RemoteProc, and your Cortex-M33 firmware brings up ExecuTorch and the Ethos-U65 delegate.
 
@@ -22,7 +24,7 @@ Before deploying, verify the following on your FRDM-IMX93 board:
    /dev/ethosu0
    ```
 
-   If `/dev/ethosu0` does not exist, the NPU is not powered and the firmware will hang at NPU initialization.
+   If `/dev/ethosu0` doesn't exist, the NPU isn't powered and the firmware will hang at NPU initialization.
 
 2. **DDR memory is reserved for the CM33.** The NXP BSP reserves two DDR regions by default:
 
@@ -120,10 +122,10 @@ The key indicators of a successful inference run:
 | `bus_status_error 0x0` | No AXI bus errors during NPU memory access |
 | `numel=1000` | MobileNet V2 output: 1000 ImageNet classification scores (one per class) |
 
-The model runs with uninitialized input data, so the output scores do not correspond to a real image classification. To get meaningful predictions, feed a real 224x224 RGB image as input.
+The model runs with uninitialized input data, so the output scores don't correspond to a real image classification. To get meaningful predictions, feed a real 224x224 RGB image as input.
 
 {{% notice Note %}}
-If the trace buffer shows `Program identifier '' != expected 'ET12'`, the `.pte` model was not loaded into DDR at `0xC0000000`. Reload the model using the steps above.
+If the trace buffer shows `Program identifier '' != expected 'ET12'`, the `.pte` model wasn't loaded into DDR at `0xC0000000`. Reload the model using the steps above.
 {{% /notice %}}
 
 ## Re-run inference
@@ -138,7 +140,7 @@ sleep 15
 cat /sys/kernel/debug/remoteproc/remoteproc0/trace0
 ```
 
-The trace buffer resets at the start of each firmware load, so you always see fresh output.
+The trace buffer resets at the start of each firmware load, so you'll always see fresh output.
 
 ## What you've accomplished and what's next
 

content/learning-paths/embedded-and-microcontrollers/observing-ethos-u-on-nxp/2-boot-nxp.md

@@ -7,15 +7,14 @@ weight: 3
 # Do not modify these elements
 layout: "learningpathall"
 ---
+## Connect to the board
 
 This section walks through powering on the board and establishing a serial console connection. If your board is already running Linux and you can log in, skip ahead to the next section.
 
-## Connect to the board
-
 You need a serial terminal to see the boot console and log in.
 
 {{% notice macOS %}}
-On macOS as your host, you will need the following set up before getting started: 
+On macOS as your host, you'll need the following set up before getting started: 
 
 - Install the [Silicon Labs USB-to-UART driver](https://www.silabs.com/developer-tools/usb-to-uart-bridge-vcp-drivers?tab=downloads)
 - Install [picocom](https://github.com/npat-efault/picocom)
@@ -24,9 +23,9 @@ On macOS as your host, you will need the following set up before getting started
    ```
 {{% /notice %}}
 
-1. Connect the board's "DEBUG" USB-C connector to your host machine.
+Connect the board's **DEBUG** USB-C connector to your host machine.
 
-2. Find the board's serial device:
+Find the board's serial device:
 
    ```bash { output_lines = "2-5" }
    ls /dev/tty.*
@@ -38,7 +37,7 @@ On macOS as your host, you will need the following set up before getting started
 
    The exact device names vary per board. Look for entries containing `usbmodem`.
 
-3. Open a serial connection using the first `usbmodem` device:
+Open a serial connection using the first `usbmodem` device:
 
    ```bash { output_lines = "2-4" }
    sudo picocom -b 115200 /dev/tty.usbmodem<SERIAL_ID_1>
@@ -47,9 +46,9 @@ On macOS as your host, you will need the following set up before getting started
    Terminal ready
    ```
 
-4. Connect the board's "POWER" USB-C connector to your host machine. You should see a red and a white LED on the board.
+Connect the board's **POWER** USB-C connector to your host machine. You should see a red and a white LED on the board.
 
-5. Wait for the boot log to scroll past in the picocom window. When it finishes, you see a login prompt:
+Wait for the boot log to scroll past in the picocom window. When it finishes, you'll see a login prompt:
 
    ```output
    NXP i.MX Release Distro 6.6-scarthgap imx93frdm ttyLP0
@@ -61,10 +60,18 @@ On macOS as your host, you will need the following set up before getting started
 If you miss the login prompt, hold the board's power button for two seconds to power off, then press it again to reboot.
 {{% /notice %}}
 
-## [Optional] Run the built-in NXP demos
+## Run the built-in NXP demos (optional)
 
 Connect the board to a monitor via HDMI and plug a mouse into the board's USB-A port. NXP includes several ML demos that run out of the box.
 
 ![NXP board built-in ML demos alt-text#center](./nxp-board-built-in-ml-demos.png "NXP board built-in ML demos")
 
+## What you've learned and what's next
+
+In this section you've:
+
+- Connected to the board via serial console
+- Booted the NXP FRDM i.MX 93 board and confirmed Linux is running
+- Verified you can access the login prompt
+
 With the board running and Linux accessible, the next step is setting up the build environment for ExecuTorch.

content/learning-paths/embedded-and-microcontrollers/observing-ethos-u-on-nxp/4-environment-setup.md

@@ -1,14 +1,14 @@
 ---
 # User change
-title: "Environment setup"
+title: "Set up the ExecuTorch build environment"
 
 weight: 5 # 1 is first, 2 is second, etc.
 
 # Do not modify these elements
 layout: "learningpathall"
 ---
 
-## For macOS: Build ExecuTorch in a Docker container
+## For macOS: build ExecuTorch in a Docker container
 
 On macOS, it’s easiest to build ExecuTorch in an Ubuntu container. This keeps your toolchain consistent with the rest of the Learning Path and avoids gaps in macOS-native cross-compilers (for example, the Arm GNU Toolchain doesn’t provide an “AArch64 GNU/Linux target” for macOS).
 
@@ -133,4 +133,12 @@ The `EthosUCompileSpec` parameters used in this guide:
 | `memory_mode`     | `Shared_Sram`         | Uses shared SRAM memory mode                   |
 {{% /notice %}}
 
+## What you've learned and what's next
+
+In this section you've:
+
+- Set up an Ubuntu 24.04 Docker container for building ExecuTorch (macOS users)
+- Installed required dependencies and created a Python virtual environment
+- Cloned the ExecuTorch repository and checked out the correct version
+
 With your build environment configured and the ExecuTorch source checked out, the next step is building and installing the ExecuTorch package.

content/learning-paths/embedded-and-microcontrollers/observing-ethos-u-on-nxp/6-build-executorch.md

@@ -1,13 +1,15 @@
 ---
 # User change
-title: "Build ExecuTorch"
+title: "Build and install ExecuTorch"
 
 weight: 7 # 1 is first, 2 is second, etc.
 
 # Do not modify these elements
 layout: "learningpathall"
 ---
 
+## Overview
+
 With the ExecuTorch source checked out and your virtual environment active, you can now build ExecuTorch and set up the Arm toolchain for Ethos-U cross-compilation.
 
 For a full tutorial on building ExecuTorch, see the Learning Path [Introduction to TinyML on Arm using PyTorch and ExecuTorch](/learning-paths/embedded-and-microcontrollers/introduction-to-tinyml-on-arm/).
@@ -72,4 +74,12 @@ git submodule update --init --recursive
 ```
 {{% /notice %}}
 
+## What you've learned and what's next
+
+In this section you've:
+
+- Installed the ExecuTorch package and verified its availability
+- Set up the Arm toolchain with Ethos-U support
+- Configured the environment for cross-compiling to Ethos-U65
+
 With ExecuTorch installed and the Arm toolchain configured, you can now compile `.pte` model files targeting the Ethos-U65 NPU.

content/learning-paths/embedded-and-microcontrollers/observing-ethos-u-on-nxp/7-build-executorch-pte.md

@@ -1,14 +1,16 @@
 ---
 # User change
-title: "Build the ExecuTorch .pte"
+title: "Build ExecuTorch models for Ethos-U65"
 
 weight: 8 # 1 is first, 2 is second, etc.
 
 # Do not modify these elements
 layout: "learningpathall"
 ---
 
-On the FRDM i.MX 93, you deploy ExecuTorch as two cooperating artifacts:
+## ExecuTorch deployment components
+
+On the FRDM i.MX93, you deploy ExecuTorch as two cooperating artifacts:
 
 |Component|Role in Deployment|What It Contains|Why It's Required|
 |---------|------------------|----------------|-----------------|
@@ -266,5 +268,13 @@ For the commands above:
 - Replace `<SD_CARD_NAME>` with the mounted volume name.
 {{% /notice %}}
 
-With both `.pte` files staged on the SD card, you can now build the Cortex-M33 `executor_runner` firmware that will load and execute them.
+## What you've learned and what's next
+
+In this section you've:
+
+- Compiled a simple add model to verify the Ethos-U65 toolchain setup
+- Built a MobileNet V2 `.pte` file with 100% NPU operator coverage
+- Staged the models on your SD card for deployment
+
+With both `.pte` files ready, you can now build the Cortex-M33 `executor_runner` firmware that will load and execute them.
 

content/learning-paths/embedded-and-microcontrollers/observing-ethos-u-on-nxp/9-build-executorch-runner-for-cm33.md

@@ -1,13 +1,16 @@
 ---
-title: Build the executor_runner firmware
+title: Build Cortex-M33 firmware for ExecuTorch
 weight: 10
-
-### FIXED, DO NOT MODIFY
+# FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
-You build the Cortex-M33 `executor_runner` firmware on your host machine, then deploy it to the FRDM i.MX 93 board.
 
-This is the core milestone of the Learning Path.
+## ExecuTorch deployment components
+
+In this section, you build the Cortex-M33 `executor_runner` firmware. You then deploy it to the FRDM i.MX 93 board.
+
+This is a key milestone. You're proving you can control the real-time ML runtime for Ethos-U65 workloads.
+
 On i.MX 93, Linux runs on the application cores, but the real-time ML runtime that talks to Ethos-U65 runs as **firmware on Cortex-M33**.
 When you can build and boot your own `executor_runner`, you've proven that the microcontroller side of the system is under your control and ready to host ML workloads.
 
@@ -243,4 +246,13 @@ The quantized operator kernels are not linked. Verify that `CMakeLists.txt` link
 
 {{% /notice %}}
 
+## What you've learned and what's next
+
+In this section you've:
+
+- Set up MCUXpresso for VS Code with the SDK and Arm toolchain
+- Cloned the executor_runner project with prebuilt ExecuTorch libraries
+- Applied critical SDK patches for GOT initialization and NPU logging
+- Built the Cortex-M33 firmware and verified it fits within memory constraints
+
 With the firmware binary built and its memory usage verified, you're ready to deploy it to the FRDM i.MX 93 and run your first inference.

content/learning-paths/embedded-and-microcontrollers/observing-ethos-u-on-nxp/_index.md

@@ -1,24 +1,20 @@
 ---
 title: Deploy ExecuTorch firmware on NXP FRDM i.MX 93 for Ethos-U65 acceleration
 
-draft: true
-cascade:
-    draft: true
-    
 minutes_to_complete: 120
 
-who_is_this_for: This is an introductory topic for developers and data scientists new to Tiny Machine Learning (TinyML), who want to observe ExecuTorch performance on a physical device.
+who_is_this_for: This is an introductory topic for developers and data scientists new to TinyML who want to observe ExecuTorch performance on a physical device.
 
 learning_objectives:
-    - Bring up a custom ExecuTorch `executor_runner` firmware on the FRDM i.MX 93 Cortex-M33 using Linux RemoteProc.
-    - Compile an ExecuTorch `.pte` model for Ethos-U65 and run inference with NPU acceleration.
-    - Understand how heterogeneous Arm systems split responsibilities across application cores, microcontrollers, and NPUs.
+    - Bring up a custom ExecuTorch `executor_runner` firmware on the FRDM i.MX 93 Cortex-M33 using Linux RemoteProc
+    - Compile an ExecuTorch `.pte` model for Ethos-U65 and run inference with NPU acceleration
+    - Understand how heterogeneous Arm systems split responsibilities across application cores, microcontrollers, and NPUs
 prerequisites:
-    - An NXP [FRDM i.MX 93](https://www.nxp.com/design/design-center/development-boards-and-designs/frdm-i-mx-93-development-board:FRDM-IMX93) development board.
-    - A USB Mini-B to USB Type-A cable, or a USB Mini-B to USB Type-C cable.
-    - Completion of [Linux on an NXP FRDM i.MX 93 board](/learning-paths/embedded-and-microcontrollers/linux-nxp-board/) (Linux setup, login access, and file transfer).
-    - Basic knowledge of Machine Learning concepts.
-    - A host computer to compile ExecuTorch libraries.
+    - An NXP [FRDM i.MX 93](https://www.nxp.com/design/design-center/development-boards-and-designs/frdm-i-mx-93-development-board:FRDM-IMX93) development board
+    - A USB Mini-B to USB Type-A cable, or a USB Mini-B to USB Type-C cable
+    - Completion of [Use Linux on an NXP FRDM i.MX 93 board](/learning-paths/embedded-and-microcontrollers/linux-nxp-board/) (Linux setup, login access, and file transfer)
+    - Basic knowledge of Machine Learning concepts
+    - A host computer to compile ExecuTorch libraries
 
 author: 
 - Waheed Brown