Zephyr

DART-MX8M-PLUS - Zephyr 4.0.0

Overview

Release Notes

For full details about this release, refer to the Release Notes.

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.

Prerequisites

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

Inside zephyrproject/zephyr add Variscite's Zephyr repository:

$ git remote add varigit https://github.com/varigit/zephyr
$ git fetch varigit v4.0-branch_var01
$ git checkout v4.0-branch_var01

Demos 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

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

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

Building a demo

With Zephyr SDK installed, the demos can be built by being inside the Python virtual environment and typing the following command inside the zephyr directory:

$ west build -p -b imx8mp_var_<dart_or_som>/MIMX8ML8/<m7_or_a53> <demo_path>

For example, building the hello_world demo for the Cortex-m7 TCM of the DART-MX8M-PLUS:

$ west build -p -b imx8mp_var_dart/MIMX8ML8/m7 samples/hello_world

The DDR variant of the Cortex-m7 demos can be built by adding /ddr at the end of the board name:

$ west build -p -b imx8mp_var_dart/MIMX8ML8/m7/ddr samples/hello_world

The built binaries zephyr.bin and zephyr.elf are inside build/zephyr.

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

If the device tree dedicated to be used with Cortex-M applications is not being currently used, the script will give instructions on how to do so:

Error: /sys/class/remoteproc/remoteproc0 not found.
Please enable remoteproc driver.
Most likely you need to use the correct device tree, for example:
fw_setenv fdt_file imx8mp-var-dart-dt8mcustomboard-m7.dtb && reboot

Manually running demos

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

To allow Cortex M7 accessing shared resources without experiencing Linux kernel conflicts, a dedicated device tree must be loaded, containing m7 label in the name, using the fdt_file environment variable in U-Boot.

This device tree disables some of the base device tree nodes in order to avoid conflicts between the main processor and Cortex M7.

File Name	Description
imx8mp-var-dart-dt8mcustomboard-m7.dtb	DART-MX8M-PLUS device tree blob for kernel >= 5.4.70 (Yocto Zeus) on DT8MCustomBoard 2.x
imx8mp-var-dart-dt8mcustomboard-legacy-m7.dtb	DART-MX8M-PLUS device tree blob for kernel >= 5.4.70 (Yocto Zeus) on on DT8MCustomBoard 1.x
imx8mp-var-som-symphony-m7.dtb	VAR-SOM-MX8M-PLUS device tree blob for kernels >= 5.4.70 (Yocto Zeus) on on Symphony-Board
imx8mp-var-som-symphony-2nd-ov5640m7.dtb	VAR-SOM-MX8M-PLUS device tree blob for kernels >= 5.4.70 (Yocto Zeus) on on Symphony-Board with 2nd OV5640

Running a demo from U-Boot

---

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

To enable Cortex-M:

=> setenv use_m7 yes; saveenv

To disable Cortex-M:

=> setenv use_m7 no; saveenv

Binary demos must be loaded to the memory type used for linking.

To use TCM:

=> setenv m7_addr 0x7E0000; saveenv

To use DDR:

=> setenv m7_addr 0x7E000000; saveenv

To set the name of the Cortex-M binary

=> setenv m7_bin myapp.bin; saveenv

The .bin file is expected in the folder /boot of the booting media.

The U-Boot boot command will handle loading the Cortex-M firmware and start Linux for DART-MX8M-PLUS.

For testing, it is possible to run the firmware manually:

=> run loadm7bin && run runm7bin

Running a demo from Linux

---

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

Note: As of 7 October 2024, NXP Application Note AN5317 states the following:

On i.MX 8M platforms, "remoteproc" stops only the Cortex-M CPU, not the Cortex-M system. Therefore, any in-flight Cortex-M bus transactions would hang after the CPU is halted and this can only be resolved with a full SoC reset. It is not recommended to stop the Cortex-M7 CPU in a production system. If the system must stop the Cortex-M7 CPU, reload the image and restart it. Then, the Cortex-M7 CPU must be in the WFI state and have no external access to the Cortex-M7 TCM memory through eDMA or other similar transactions. A possible solution is to implement a handshake between the Cortex-M and Cortex-A CPUs to confirm that the Cortex-M CPU is safe to stop or reset.

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 DART-MX8M-PLUS software overview page.
2. Click on Release Notes.
3. Look for the Cortex m7 Linux remoteproc support row in the release notes to see which version is supported. If Cortex m7 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 m7, it should be running already by U-Boot

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

If the state is 'running', stop the m7

# 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

Running Cortex-A demos

Running a demo from U-Boot

Transfer built binary zephyr.bin to the boot directory of the SD card or USB drive and plug it into the carrier board.

Power the board up and stop U-Boot execution at prompt.

Load zephyr.bin from the SD card:

=> load mmc $mmcdev:$mmcpart 0xc0000000 /boot/zephyr.bin
36926 bytes read in 5 ms (7 MiB/s)
=> dcache flush; icache flush; go 0xc0000000
## Starting application at 0xc0000000 ...

Load zephyr.bin from the USB drive:

=> usb start
starting USB...
Bus usb@38100000: extcon_ptn5150_phy_mode: phy mode is host
...
=> load usb 0:1 0xc0000000 zephyr.bin
36926 bytes read in 9 ms (3.9 MiB/s)
=> dcache flush; icache flush; go 0xc0000000
## Starting application at 0xc0000000 ...

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.

JTAG interface

The VAR-SOM-MX8M-PLUS exposes JTAG interface via an optional 10-pin header, on the SOM top left side.
The DART-MX8M-PLUS exports JTAG interface via an optional 10-pin header, on the DT8MCustomBoard top side.

Here is the pinout:

pin	signal	description	pin	signal	description
1	JTAG_VREF	JTAG IO reference voltage, connected to SOM_3V3_PER via 150 Ohm.	2	JTAG_TMS	JTAG Mode Select signal
3	GND	Digital Ground	4	JTAG_TCK	JTAG Clock signal, include PD of 8.2K Ohm.
5	GND	Digital Ground	6	JTAG_TDO	JTAG Data Out signal
7	GND	Digital Ground	8	JTAG_TDI	JTAG Data In signal
9	JTAG_TRST_B	JTAG Reset signal, active low signal	10	POR_B	Programmer Reset, used to put the SOC in reset state.

Please refer to SoM datasheet for further details.