LP: Innexis ANA Zena onboarding

content/learning-paths/automotive/innexis_ana_zena/1_understand_zena_css.md

@@ -0,0 +1,34 @@
+---
+title: Understand the Zena CSS virtual platform
+weight: 2
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Understand the Zena CSS virtual platform
+
+In [Innexis ANA](https://www.siemens.com/en-gb/products/ic/hav/innexis/architecture-native-acceleration/), a *chamber* provides the environment in which you create and run a virtual platform. The **Arm-Zena-CSS** vSoC describes the virtual hardware. The [**Arm-Zena-CSS EWAOL Software Stack**](https://arm-zena-css.docs.arm.com/en/v2.2/overview.html) supplies the software images used to boot it.
+
+This Learning Path follows Siemens Innexis ANA **2026.2**. ANA menus, supplied assets, and software behavior may change in later releases. Use the ANA User Guide that matches your chamber version when a screen differs from this tutorial.
+
+Zena CSS has more than one processing area. You will inspect these consoles after starting the virtual platform:
+
+| Console in ANA | What to look for |
+| --- | --- |
+| **RSE** | Firmware messages associated with the Root of Security for the system. |
+| **Safety Island** | SCP firmware messages from the Safety Island. |
+| **Primary Compute Secure** | Secure-world and boot-stage messages for the primary-compute system. |
+| **Primary Compute** | EWAOL Linux boot messages and the login prompt. |
+
+The RSE starts the boot process on a Cortex-M55. It prepares firmware for the Cortex-R82AE Safety Island and the Primary Compute. SCP firmware on the Safety Island then powers on the Primary Compute.
+
+Trusted Firmware-A (TF-A) and OP-TEE run in the Primary Compute secure world. U-Boot and systemd-boot lead to Linux in the normal world. The two Primary Compute console views show software running on the same Cortex-A720AE cores, not two separate groups of CPUs. See the [Arm Zena CSS boot process](https://arm-zena-css.docs.arm.com/en/latest/design/boot_process.html) for the reference software flow.
+
+The firmware consoles help you see how the virtual system reaches Linux. They do not, by themselves, demonstrate that an application is secure or that a product has passed a security assessment.
+
+For this Learning Path, your first working result is the **EWAOL Linux login prompt on the primary-compute console**. You will then inspect the guest from its shell. You do not need to change firmware or rebuild the software stack.
+
+## Check your understanding
+
+Before continuing, locate **Arm-Zena-CSS** and its **EWAOL Software Stack** in your chamber. If either is absent, ask the chamber administrator which Zena assets are available.

content/learning-paths/automotive/innexis_ana_zena/2_create_and_start.md

@@ -0,0 +1,68 @@
+---
+title: Create and start a Zena CSS virtual platform
+weight: 3
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Create and start a Zena CSS virtual platform
+
+Use the ANA Web IDE to create a new virtual-platform project. This Learning Path uses the supplied EWAOL images, so you do not need to build software before the first boot.
+
+## Create the project
+
+1. Sign in to the ANA chamber provided by your administrator and open the **Web IDE**.
+2. Start the **Create a New Virtual Platform Project** workflow described in your Innexis ANA User Guide.
+3. Select **Arm-Zena-CSS** as the vSoC.
+4. Select **Arm-Zena-CSS EWAOL Software Stack** as the software stack.
+5. Give the project a recognizable name and finish the creation workflow. Record any configuration option you change from its default.
+
+![ANA project form with Arm-Zena-CSS and its EWAOL software stack selected#center](create_zena_project.png "Create a Zena CSS virtual platform project")
+
+The new project appears in the Web IDE with a Zena CSS virtual platform and its selected EWAOL software. Verify both selections before starting. Project creation alone does not show that Linux can boot.
+
+![Zena CSS project and virtual SoC configuration in the ANA Web IDE#center](project_conf.png "Zena CSS project configuration")
+
+
+{{% notice Note %}}
+If the project workflow offers a different Zena or EWAOL variant, record its full name and check with the chamber administrator before continuing. The prebuilt software must match the chamber host and vSoC configuration.
+{{% /notice %}}
+
+## Configure Host Access before starting
+
+Set up the folder for the file-sharing exercise while the virtual platform is stopped. ANA disables **Host Filesystem - Access Path** and **Browse** while a VP is running.
+
+1. In the Web IDE **Explorer**, create a folder in your new project for the shared files, such as **test_folder**. The **New Folder** control is in the **WORKSPACE** section of Explorer.
+2. Open **Lab Manager**, select the new virtual platform, and expand **Software > Host Access**.
+3. Next to **Host Filesystem - Access Path**, choose **Browse**. The directory selector shows the ANA project workspace, not folders on your local computer. Select the shared folder in your project.
+4. Set **Host Filesystem - Guest Mount ID** to **share** and choose **Save**.
+
+Confirm that **Access Path** shows the selected project folder and **Guest Mount ID** is **share** before choosing **Start**. You will use this folder and mount ID in the file-sharing exercise.
+
+![ANA Host Access settings with a project folder and guest mount ID share#center](ana_host_access.png "Configure Host Access before starting")
+
+## Start the virtual platform
+
+1. Open **Lab Manager** from the Web IDE.
+2. Select the virtual platform you just created.
+3. Choose **Start**.
+4. Open the **Serial Console** view and select the primary-compute console.
+
+![ANA Lab Manager showing a stopped virtual platform and its Start button#center](ana_lab_manager_start.png "Start the Zena CSS virtual platform")
+
+Lab Manager shows that the selected virtual platform is starting or running, and the primary-compute console begins displaying boot messages. Boot may take time; wait for a Linux login prompt before treating it as complete.
+
+![Primary Compute serial console at the EWAOL Linux login prompt#center](primary_compute_console.png "EWAOL Linux login prompt")
+
+
+{{% notice Note %}}
+If the virtual platform stops before reaching a login prompt, record its Lab Manager state and the last visible console messages before retrying. Check the selected vSoC, software stack, and chamber compatibility.
+{{% /notice %}}
+
+
+## Record the starting configuration
+
+Keep a short record of the ANA release, chamber host type, project name, vSoC selection, software-stack name, and any memory setting you changed.
+
+You are ready to continue when you can open the console for the **same project** that you started.

content/learning-paths/automotive/innexis_ana_zena/3_observe_boot.md

@@ -0,0 +1,103 @@
+---
+title: Observe Zena CSS boot and inspect Linux
+weight: 4
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Observe Zena CSS boot and inspect Linux
+
+Zena CSS exposes separate consoles for its RSE, Safety Island, and primary-compute software. Check each view before entering commands in the Linux guest.
+
+## Follow the boot handoff
+
+Use this sequence to connect the console views to the [Arm Zena CSS boot process](https://arm-zena-css.docs.arm.com/en/latest/design/boot_process.html):
+
+1. The Runtime Security Engine (RSE) starts first and prepares the Safety Island firmware and the Primary Compute boot image.
+2. SCP firmware on the Safety Island starts and powers on the Primary Compute.
+3. Trusted Firmware-A (TF-A) starts in the Primary Compute secure world. OP-TEE provides secure-world services, while U-Boot continues the normal-world boot.
+4. U-Boot starts systemd-boot, which starts the Linux kernel and EWAOL userspace.
+
+The Primary Compute Secure and Primary Compute views do not represent separate sets of CPUs. The secure-world software and Linux use the same application processor cores. This sequence describes the handoff; console timestamps from different views are not a single synchronized timeline.
+
+## Inspect the boot consoles
+
+In ANA's **Serial Console** view, select each console for your virtual platform:
+
+1. **RSE:** look for TF-M or RSE firmware messages.
+2. **Safety Island:** look for an SCP firmware startup message.
+3. **Primary Compute Secure:** look for TF-A or OP-TEE boot messages.
+4. **Primary Compute:** wait for EWAOL Linux to finish booting.
+
+![ANA Serial Console showing Safety Island firmware output and the console selector#center](ana_console_selector.png "Select a Zena CSS boot console")
+
+The primary-compute console reaches a Linux login prompt. The other consoles show messages from different parts of the system; do not expect the Linux shell on those views.
+
+Record one identifying line from each console and the exact text of the Linux login prompt. If early firmware messages are no longer visible, record what is available instead of inferring that the stage did not run. A firmware message does not replace a Linux boot check or prove that image authentication succeeded.
+
+## Log in and inspect the guest
+
+Use the login details supplied for your chamber and software image. The Siemens reference guide uses the root account for its EWAOL example.
+
+Run the following commands in the **primary-compute Linux console**:
+
+```bash
+cat /etc/os-release; uname -m; uname -r; grep -E '^(MemTotal|MemAvailable):' /proc/meminfo; df -h /
+```
+
+`uname -m` reports the Linux guest architecture, commonly `aarch64`. The other commands report this guest's actual OS release, kernel, memory, and root-filesystem capacity. The author's Zena guest returned:
+
+```output
+ID=ewaol
+NAME="Edge Workload Abstraction and Orchestration Layer"
+VERSION="v2.1.0 (styhead)"
+VERSION_ID=v2.1.0
+VERSION_CODENAME="styhead"
+PRETTY_NAME="Edge Workload Abstraction and Orchestration Layer v2.1.0 (styhead)"
+CPE_NAME="cpe:/o:openembedded:ewaol:v2.1.0"
+aarch64
+6.6.54-yocto-standard
+MemTotal:        8120232 kB
+MemAvailable:    7857784 kB
+Filesystem      Size  Used Avail Use% Mounted on
+/dev/root        28G  1.3G   25G   5% /
+```
+
+
+## Check which CPUs Linux can use
+
+In the same **Primary Compute Linux console**, inspect the CPUs present and online in this guest:
+
+```bash
+cat /sys/devices/system/cpu/present
+cat /sys/devices/system/cpu/online
+grep -c '^processor' /proc/cpuinfo
+lscpu
+```
+
+The `present` file lists CPUs Linux identifies as present. The `online` file lists CPUs available to the scheduler. The count from `/proc/cpuinfo` shows the processor entries in this Linux guest; it is not a count of every processing element in the Zena CSS vSoC.
+
+The author's Zena Linux guest returned these relevant lines. Your values can differ if your virtual platform uses another CPU configuration:
+
+```output
+0-15
+0-15
+16
+Architecture:             aarch64
+CPU(s):                   16
+  On-line CPU(s) list:    0-15
+  Model name:             Cortex-A720AE
+  Core(s) per cluster:  16
+  Cluster(s):           1
+```
+
+Linux sees 16 online Cortex-A720AE CPUs in this run. The Cortex-R82AE Safety Island and Cortex-M55 RSE run separate firmware and do not appear as extra Linux CPUs. The secure-world console also does not represent another set of CPUs. Compare the reported count with the CPU configuration selected for your VP.
+
+The cluster fields describe the topology presented to this Linux guest. They do not, by themselves, establish the vSoC's internal cluster layout or the topology of a future physical device.
+
+The vSoC's configured DRAM and the RAM usable by its Linux image can differ. Compare the Linux-visible **MemTotal** with the project configuration when you document the environment.
+
+If the login prompt does not appear, return to the primary-compute console and inspect its last boot messages. If a command is unavailable in your image, record the command and error and use the available files under **/proc** to inspect the same property.
+
+You are ready to continue when you can log in, identify the guest OS and resources, and explain why the RSE and Safety Island cores are absent from the Linux CPU list. The CPU output shown here comes from the author's Zena guest; record the values from your own VP.

content/learning-paths/automotive/innexis_ana_zena/4_connect_to_guest.md

@@ -0,0 +1,86 @@
+---
+title: Connect to the Zena CSS Linux guest
+weight: 5
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Connect to the Zena CSS Linux guest
+
+Find this VP's port mapping, authorize an SSH tunnel, and connect through the external port mapped to guest port `22`. The port and target address belong to the selected VP. Get them from ANA each time rather than copying values from another project.
+
+## Check the mapping and guest listener
+
+In **Lab Manager > Networking > Port Mapping** (or **Device Access Ports**), select the Zena VP you started.
+
+![ANA Port Mapping panel with the Authorize button and generated SSH tunnel command#center](ana_port_mapping.png "Authorize an ANA SSH tunnel")
+
+Find the TCP entry whose **target port** is `22`. Record its target IP and external port in your private run notes. Read the network prefix from the guest interface. Do not treat every listed external port as an SSH port.
+
+![ANA Port Mapping table showing the external TCP port mapped to guest port 22#center](ana_port_mapping2.png "Find the SSH port mapping")
+
+On the **primary-compute Linux console**, inspect the guest network and SSH service:
+
+```bash
+ip -4 -br addr
+systemctl is-active sshd.socket
+```
+
+The tested guest returned:
+
+```output
+lo               UNKNOWN        127.0.0.1/8
+eth0             UP             192.168.122.153/24 metric 10
+active
+```
+
+Compare the target IP in ANA's port mapping with the addresses shown by `ip -br addr`. If they differ, confirm that the mapping belongs to the VP you started. For the Zena run shown here, the mapping targeted `192.168.122.39`, while `eth0` had `192.168.122.153/24` from DHCP. Both addresses are in the same `/24` subnet. The following command added the mapped target IP temporarily as a second address on `eth0`:
+
+```bash
+ip addr add 192.168.122.39/24 dev eth0
+ip -4 addr show dev eth0 | grep 'inet '
+```
+
+The output then showed both `192.168.122.153/24` and `192.168.122.39/24`, with the latter marked `secondary`.
+
+```
+inet 192.168.122.153/24 metric 10 brd 192.168.122.255 scope global dynamic eth0
+inet 192.168.122.39/24 scope global secondary eth0
+```
+
+Use the target IP from **your current mapping**, and the prefix for **your guest subnet**; do not copy `192.168.122.39/24` unless it matches your VP. This address is lost when the guest restarts.
+
+The author's guest reported `sshd.socket` as active. This does not confirm that the ANA tunnel works. If the socket is inactive on your image, start it and confirm it is active:
+
+```bash
+systemctl start sshd.socket
+systemctl is-active sshd.socket
+```
+
+
+## Authorize the tunnel and connect
+
+In ANA, select or register your local SSH public key and choose **Authorize** for this VP. Copy the complete tunnel command that ANA generates and run it on your **local computer**. Keep that terminal open. Do not include the generated endpoint or key material in a published example.
+
+In a second **local terminal**, enter the external port from the mapping whose target port is `22`:
+
+```bash
+printf 'External port mapped to guest port 22: '
+read -r ANA_SSH_PORT
+ssh -4 -p "$ANA_SSH_PORT" root@127.0.0.1
+```
+
+Run this command in the resulting **guest SSH shell**:
+
+```bash
+uname -m; hostname
+```
+
+The verified SSH shell returned `aarch64` for `uname -m`; `hostname` returned `ana-rd-zena`. A response from the serial console alone does not verify SSH; run the check through the authorized local tunnel.
+
+If the connection fails before SSH authentication, check the terminal running the ANA tunnel. In this run, it initially reported `channel ... open failed: connect failed: No route to host`. The SSH connection succeeded after the mapped guest IP was added, without restarting the tunnel. If the error persists after confirming the guest address and SSH listener, give the chamber administrator the VP name, current mapping, and redacted tunnel error so they can check the relay route.
+
+## What you have learned
+
+You can reach the selected virtual platform from your development computer using its current ANA port mapping. Keep the authorized tunnel open if you use it to copy files in a later exercise.