Skip to content

Zephyr 4.3.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 and install SDK version 0.17.4:

$ git remote add varigit https://github.com/varigit/zephyr
$ git fetch varigit v4.3-branch_var01
$ git checkout v4.3-branch_var01
$ west update
$ rm -rf ~/zephyr-sdk-*
$ west sdk install --version 0.17.4

Demos pins

Default M7 pins used by the demos are:

Function SoC balls DART-MX95 pins DT8MCB pins Sonata-Board pins Notes
LPUART3 RX/TX P44 / N51 J2.87 / J2.89 J12.11 / J12.13 J6.11 / J6.13
PIN_GPIO_IO32: GPIO output N45 J2.28 J14.8 J8.8 This GPIO pin is used by the gpio-leds driver but is disabled by default and must be explicitly enabled in the Zephyr Device Tree for it to work.
PIN_GPIO_IO35: GPIO input N45 J2.46 J14.10 J8.10 This GPIO pin is used by the gpio-keys driver but is disabled by default and must be explicitly enabled in the Zephyr Device Tree for it to work.

Available demos

The following demos have been tested and validated for the DART-MX95:

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

System Manager (SM) configuration to support Cortex-M7

The System Manager (SM) is an application that runs on the Cortex-M33. By default, the SM build configuration does not support the Cortex-M7 core.

To enable resource assignment to Cortex-M7, edit: 

  sources/meta-variscite-bsp-imx/conf/machine/imx95-var-dart.conf
and change: 
  SYSTEM_MANAGER_CONFIG = "mx95evk"
to: 
  SYSTEM_MANAGER_CONFIG = "dart-mx95-m7"

This change builds the SM using dart-mx95-m7.cfg, which allows assigning hardware resources to the Cortex-M7 core. There is no need to set the fdt_file environment variable in U-Boot, as it is configured automatically. A dedicated device tree, with an m7 suffix in its name, is also selected automatically to help separate resources assigned to the Cortex-M7 from those used by the Linux kernel.

When running the Zephyr samples: 

  samples/basic/blinky
  samples/basic/button
the GPIO pins PIN_GPIO_IO32 and PIN_GPIO_IO35, as well as their GPIO bank GPIO5, must be moved from the Cortex-A55 domain to the Cortex-M7 domain in the dart-mx95-m7.cfg SM configuration. Otherwise, the Cortex-M7 core will not be able to access these GPIOs, and the blinky and button samples will not operate as expected.

Additionally, the GPIO5 controller node must be disabled in the Linux device tree (for example, by setting status = "disabled") to prevent the Linux kernel from using this GPIO bank while it is assigned to the Cortex-M7 core.

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 imx95_var_dart/MIMX9596/<m7_or_a55> <demo_path>

For example, building the hello_world demo for the Cortex-m7 TCM of the VAR-SOM-MX95:

$ west build -p -b imx95_var_dart/MIMX9596/m7 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 imx95-var-dart:

root@imx95-var-dart:~# /etc/remoteproc/variscite-rproc-u-boot -f /boot/zephyr.bin
Configuring for TCM memory
+ fw_setenv m7_addr 0x203c0000
+ fw_setenv fdt_file imx95-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 imx95-var-dart:

root@imx95-var-dart:~# /etc/remoteproc/variscite-rproc-linux -f /lib/firmware/zephyr.elf
[  212.888118] remoteproc remoteproc1: powering up imx-rproc
[  212.899215] remoteproc remoteproc1: Booting fw image zephyr.elf, size 515836
[  212.912070] remoteproc remoteproc1: No resource table in elf
[  213.444675] remoteproc remoteproc1: 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.

To allow the Cortex-M7 to access shared resources without experiencing Linux kernel conflicts, a dedicated device tree must be loaded, by selecting the right version with the symbolic link in the /boot folder of the booting media. These device trees contain m7 label in their name.

The below table lists dtb blob file names for VAR-SOM-MX95 (on the Symphony Board) and DART-MX95 (on DT8MCustomBoard) with support for the M7:

File Name
Description
imx95-var-dart-sonata-m7.dtb DART-MX95 device tree blob on Sonata-Board
imx95-var-dart-dt8mcustomboard-m7.dtb DART-MX95 device tree blob for DT8MCustomBoard 3.x.

These device trees disable some of the base device tree nodes in order to avoid conflicts between the Cortex-A55 processors and Cortex-M7.

For the full list of device tree blob files, refer to the "Build Results" section in the appropriate wiki page for the specific Yocto/Debian release you are using.

Running a demo from U-Boot

To assist in loading M7 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_m7 yes; saveenv

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

=> setenv use_m7 no; saveenv

Note that the Cortex A55s and M7 have a different memory addressing "view" that is documented in the reference manual. Additionally, the bootaux command for the M7 uses secure aliases from the M7'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 m7_addr 0x203C0000
=> setenv m7_addr_auxview 0x00000000
=> saveenv

To set the name of the Cortex-M binary

=> setenv m7_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-M7 boot process manually:

=> run loadm7bin && run runm7bin

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

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

Running a demo from Linux

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

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

Increase kernel loglevel while debugging:

# sysctl kernel.printk=7;

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

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

Load new firmware

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

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

Run the new firmware

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

By default, Linux disables unused clocks. Certain M7 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 M7 examples, it is recommended to override this. The easiest way to achieve this is to append the bootarg "clk_ignore_unused."

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 0xd0000000 /boot/zephyr.bin
36926 bytes read in 5 ms (7 MiB/s)
=> dcache flush; icache flush; go 0xd0000000
## Starting application at 0xd0000000 ...

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 0xd0000000 zephyr.bin
36926 bytes read in 9 ms (3.9 MiB/s)
=> dcache flush; icache flush; go 0xd0000000
## Starting application at 0xd0000000 ...

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 DART-MX95 exports JTAG interface via an optional 10-pin header, on the Sonata-Board top side. The DART-MX95 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 10K 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.