Zephyr

- Zephyr

Overview

Zephyr

From the Introduction section of the Zephyr Project Documentation:

The Zephyr OS is based on a small-footprint kernel designed for use on 
resource-constrained and embedded systems: from simple embedded environmental 
sensors and LED wearables to sophisticated embedded controllers, smart watches, 
and IoT wireless applications.

Check DART-MX8M-PLUS Zephyr page for more details about supported features of this release.

Prerequisites

Install Zephyr SDK and its dependencies by following the latest version of Zephyr’s Getting Started Guide.

Demos pins

Based on release	Zephyr
Release git	[/tree/ ]
Release branch	[/tree/ ]
Date
Supported platforms
SOM revision
Carrier board revision

DART-MX8M-PLUS

Sections

Default pins

Default pins used by the demos are:

DART-MX8M-PLUS
Function	SoC balls	SoM pins	DT8MCB pins	Notes
UART3 RX/TX	AE6 / AJ4	J2.87 / J2.89	J12.11 / J12.13	Zephyr debug console
GPIO3_IO09	N24	J1.46	J41.3	Output of the Blinky/Button demo Pin referenced to 1.8V
GPIO3_IO08	L24	J1.50	J41.5	Input of the Button demo Pin referenced to 1.8V

VAR-SOM-MX8M-PLUS
Function	SoC balls	SoM pins	Symphony pins	Notes
UART4 RX/TX	AH5 / AJ5	J1.115 / J1.171	J18.9 / J18.7	Zephyr debug console
GPIO3_IO14	R26	J1.79	J17.10	Output of the Blinky/Button demo Pin referenced to 1.8V
GPIO3_IO06	R25	J1.84	J17.3	Input of the Button demo Pin referenced to 1.8V

Available Demos

• samples/hello_world
• samples/basic/blinky
• samples/basic/button

Releases

mx8mp-zephyr-4.0.0-v1.0

  *HARDWARE_NAME = DART-MX8M-PLUS

• RELEASE_NAME = mx8mp-zephyr-4.0.0-v1.0
• RELEASE_LINK = mx8mp-zephyr-4.0.0-v1.0
• SDK_PATH = ~/zephyrproject/zephyr
• SDK_GIT_URL = https://github.com/varigit/zephyr
• SDK_GIT_BRANCH = v4.0-branch_var01
• ZEPHYR_VERSION = 4.0.0
• BOARD_FOLDER = boards/variscite/imx8mp_var
• DOCS_FOLDER = doc
• PINS_SECTION = DART-MX8M-PLUS_PINS_SECTION
• DEMOS_SECTION = DART-MX8M-PLUS_DEMOS_SECTION
• DTBS_SECTION = DART-MX8M-PLUS_DTBS_SECTION
• JTAG_SECTION = DART-MX8M-PLUS_JTAG_SECTION
• NXP_REFERENCE_KIT = EVK-MIMX8MP
• YOCTO_RELEASE_TAG = mx8mp-yocto-scarthgap-6.6.23_2.0.0-v1.1

DART-MX93

Sections

Default pins

Default pins used by the demos are:

DART-MX93
Function	SoC balls	SoM pins	DT8MCB pins	Notes
UART7 RX/TX	M21 / M20	J2.87 / J2.89	J12.11 / J12.13	Zephyr debug console
GPIO4_IO01	AA10	J1.11	J12.14	Output of the Blinky/Button demo
GPIO2_IO27	W21	J2.54	J13.17	Input of the Button demo

VAR-SOM-MX93
Function	SoC balls	SoM pins	Symphony pins	Notes
UART7 RX/TX	M21 / M20	J1.175 / J1.124	J18.5 / J18.3	Zephyr debug console
GPIO4_IO28	U4	J1.75	J17.6	Output of the Blinky/Button demo Pin referenced to 1.8V
GPIO2_IO27	W21	J1.69	J18.2	Input of the Button demo

Available Demos

• samples/hello_world
• samples/basic/blinky
• samples/basic/button

Releases

mx93-zephyr-4.0.0-v1.0

  *HARDWARE_NAME = VAR-SOM-MX93

• RELEASE_NAME = mx93-zephyr-4.0.0-v1.0
• RELEASE_LINK = mx93-zephyr-4.0.0-v1.0
• SDK_PATH = ~/zephyrproject/zephyr
• SDK_GIT_URL = https://github.com/varigit/zephyr
• SDK_GIT_BRANCH = v4.0-branch_var01
• ZEPHYR_VERSION = 4.0.0
• BOARD_FOLDER = boards/variscite/imx93_var_dart
• DOCS_FOLDER = doc
• PINS_SECTION = DART-MX93_PINS_SECTION
• DEMOS_SECTION = DART-MX93_DEMOS_SECTION
• DTBS_SECTION = VAR-SOM-MX93_DART-MX93_DTBS_SECTION
• JTAG_SECTION = VAR-SOM-MX93_DART-MX93_JTAG_SECTION
• NXP_REFERENCE_KIT = EVK-MIMX93
• YOCTO_RELEASE_TAG = mx93-yocto-mickledore-6.1.36_2.1.0-v2.4

Available demos

The following demos have been tested and validated for the VAR-SOM-MX93 and DART-MX93:

• samples/hello_world
• samples/basic/blinky
• samples/basic/button

Running Cortex-M demos

Running a Demo using Yocto Scripts

In Yocto Dunfell and newer, Variscite provides scripts to simplify loading firmware via U-Boot or Linux:

Script	Description
/etc/remoteproc/variscite-rproc-u-boot	Configure U-Boot to load firmware on boot
/etc/remoteproc/variscite-rproc-linux	Load and run firmware using Linux remoteproc framework

Examples

variscite-rproc-u-boot example on imx8mp-var-dart:

root@imx8mp-var-dart:~# /etc/remoteproc/variscite-rproc-u-boot -f /boot/zephyr.bin
Configuring for TCM memory
+ fw_setenv m7_addr 0x7E0000
+ fw_setenv fdt_file imx8mp-var-dart-dt8mcustomboard-m7.dtb
+ fw_setenv use_m7 yes
+ fw_setenv m7_bin zephyr.bin

Finished: Please reboot, the m7 firmware will run during U-Boot

variscite-rproc-linux example on imx8mp-var-dart:

root@imx8mp-var-dart:~# /etc/remoteproc/variscite-rproc-linux -f /lib/firmware/zephyr.elf
[  212.888118] remoteproc remoteproc0: powering up imx-rproc
[  212.899215] remoteproc remoteproc0: Booting fw image zephyr.elf, size 515836
[  212.912070] remoteproc remoteproc0: No resource table in elf
[  213.444675] remoteproc remoteproc0: remote processor imx-rproc is now up

Manually running demos

To run manually run Cortex M demos it is necessary to manually load the appropriate device tree file.

Running a demo from U-Boot

---

To assist in loading M33 firmware from U-Boot prior to Linux boot, Variscite has created a dedicated set of U-Boot environment commands.

To allow Cortex-M accessing shared resources without experiencing Linux kernel conflicts, a dedicated device tree must be loaded.

To enable Cortex-M U-Boot auto-loading:

=> setenv use_m33 yes; saveenv

To disable Cortex-M U-Boot auto-loading:

=> setenv use_m33 no; saveenv

Note that the Cortex A55s and M33 have a different memory addressing "view" that is documented in the reference manual. Additionally, the bootaux command for the M33 uses secure aliases from the M33's point of view. Thus, two variables must be set properly in order to set the loading address (defaults used in the example below):

=> setenv m33_addr 0x201E0000
=> setenv m33_addr_auxview 0x1FFE0000
=> saveenv

To set the name of the Cortex-M binary

=> setenv m33_bin cm_hello_world.bin; saveenv

The .bin file is expected to exist in the directory /boot of the booting media.

After enabling as above, the U-Boot boot command will handle loading the Cortex-M firmware when the system begins the boot process. For testing, it is possible to invoke the Cortex-M33 boot process manually:

=> run loadm33bin && run runm33bin

After booting in Linux, the M33 will be listed as in the "attached" state by remoteproc:

# cat /sys/class/remoteproc/remoteproc0/state 
attached

Running a demo from Linux

---

The Linux remoteproc framework can be used to load the Cortex-M33 firmware from Linux userspace.

The U-Boot M33 auto-loading must not be currently enabled in order to allow for remoteproc control and loading of the M33.

Increase kernel loglevel while debugging:

# sysctl kernel.printk=7;

If the state is 'running', stop the Cortex-M33

# echo stop > /sys/class/remoteproc/remoteproc0/state

Load new firmware

# echo cm_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware

The .elf file is expected to exist in the /lib/firmware directory

Run the new firmware

# echo start > /sys/class/remoteproc/remoteproc0/state

By default, Linux disables unused clocks. Certain M33 examples may use peripherals which are not enabled in Linux. Depending on the clock source, Linux may disable the clock by default, resulting in the example/peripheral not functioning. Therefore, when running M33 examples, it is recommended to override this. The easiest way to achieve this is to append the bootarg "clk_ignore_unused."

Running a demo from Linux

---

The Linux remoteproc framework can be used to load the Cortex m4 firmware from Linux userspace.

Note: The Linux remoteproc framework is not supported by all Yocto/B2Qt/Debian/Android releases.

Follow these steps to verify the Linux remoteproc framework is supported for your release:

1. Select the software release from the VAR-SOM-MX93 software overview page.
2. Click on Release Notes.
3. Look for the Cortex m4 Linux remoteproc support row in the release notes to see which version is supported. If Cortex m4 Linux remoteproc support is not in the release notes table, the Linux remoteproc framework is not supported.
   
   

After confirming Linux remoteproc support, follow these steps to use the framework:

Boot Linux after following the steps in #Running a demo from U-Boot

Increase kernel loglevel while debugging:

# sysctl kernel.printk=7;

Check the state of the m4, it should be running already by U-Boot

# cat /sys/class/remoteproc/remoteproc0/state

If the state is 'running', stop the m4

# echo stop > /sys/class/remoteproc/remoteproc0/state

Load new firmware (.elf file must already exist in /lib/firmware directory)

# echo hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware

Run the new firmware

# echo start > /sys/class/remoteproc/remoteproc0/state

Debugging a demo

JTAG Hardware

The Cortex-M firmware can be debugged using a JTAG debugger. Variscite recommends using a Segger J-Link Ultra+, J-Link Pro, or J-Link Wi-Fi debugger. You may also need a 9-pin Cortex-M adapter from Segger.

Note: If you encounter issues while using the ARM-JTAG-20-10 adapter from Olimex (such as the "TDO is constant high" error), you may need to leave pin 9 floating. This can be done by cutting the copper trace between the R2 pads, as indicated in the product page FAQ.