phyBOARD-Polis i.MX8M Mini

Overview

The phyBOARD-Polis, either a development platform for the phyCORE-i.MX 8M Mini/Nano, or a powerful, industry-compatible single-board computer for immediate implementation of your product idea. As a development platform, the phyBOARD-Polis serves as reference design for your customer-specific application and enables parallel development of the software and carrier board for the phyCORE-i.MX 8M Mini/Nano.

The phyBOARD-Polis is composed of a quad Cortex-A53 cluster and a single Cortex-M4 core.

As a powerful, industrial single-board computer (SBC), the phyBOARD-Polis is equipped with a variety of standard interfaces which are available on standard or socket/pin header connectors, while interesting extensions of the phyCORE-i.MX 8M Mini/Nano features such as CAN FD, WLAN and an integrated TPM chip further extend the range of applications that can be developed with the phyCORE-i.MX 8M Mini/Nano.

Board features:
- RAM: 512MB - 4GB (LPDDR4)
- Storage:
  - 4GB - 128GB eMMC
  - 8MB - 128MB SPI NOR Flash
  - microSD Interface
  - 4kB EEPROM
- Wireless:
  - WiFi: 802.11 b/g/n (ac) 2.4 GHz / 5 GHz
  - BLE 4.2
- USB:
  - 1x USB2.0 OTG
  - 1x USB2.0
- Ethernet: 1x 10/100/1000BASE-T
- Interfaces: - 1x RS232 / RS485 - 2x UART - 3x I²C - 2x SPI - Up to 4x PWM - 4x SAI - 1x MIPI CSI-2 - 1x MIPI DSI-2 - 2x MMC/SD/SDIO - 1x PCIe (mini PCIE)
- LEDs:
  - 1x Status LED (3 Color LED)
  - 1x Debug UART LED
- Debug
  - JTAG 20-pin connector
  - MicroUSB for UART debug, two COM ports for A53 and M4

More information about the board can be found at the PHYTEC website.

Supported Features

The phyboard_polis board supports the hardware features listed below.

on-chip / on-board: Feature integrated in the SoC / present on the board.
2 / 2: Number of instances that are enabled / disabled.
Click on the label to see the first instance of this feature in the board/SoC DTS files.
vnd,foo: Compatible string for the Devicetree binding matching the feature.
Click on the link to view the binding documentation.

`phyboard_polis/mimx8mm6/a53` target

On-target memory for this board target: 1 MiB of RAM, N/A of Flash.

Type	Location	Description	Compatible
CPU	on-chip	ARM Cortex-A53 CPU1 3	`arm,cortex-a53`
Clock control	on-chip	i.MX CCM (Clock Controller Module) IP node1	`nxp,imx-ccm`
Counter	on-chip	NXP MCUX General-Purpose Timer (GPT)2	`nxp,imx-gpt`
Ethernet	on-chip	NXP ENET IP Module1	`nxp,enet`
	on-chip	NXP ENET MAC/L2 Device1	`nxp,enet-mac`
	on-chip	NXP ENET MDIO Features1	`nxp,enet-mdio`
	on-chip	NXP ENET PTP (Precision Time Protocol) Clock1	`nxp,enet-ptp-clock`
GPIO & Headers	on-chip	i.MX GPIO1 4	`nxp,imx-gpio`
I2C	on-chip	NXP II2C4	`nxp,ii2c`
Interrupt controller	on-chip	ARM Generic Interrupt Controller v31	`arm,gic-v3`
LED	on-board	Group of GPIO-controlled LEDs1	`gpio-leds`
Miscellaneous	on-chip	NXP i.MX Resource Domain Controller (RDC)1	`nxp,rdc`
Pin control	on-chip	This compatible binding should be applied to the device’s iomuxc DTS node1	`nxp,imx-iomuxc`
Pin control	on-chip	The node has the ‘pinctrl’ node label set in MCUX SoC’s devicetree1	`nxp,imx8mp-pinctrl`
PWM	on-chip	NXP i.MX PWM controller4	`nxp,ipwm`
Serial controller	on-chip	This binding gives a base representation of the NXP iMX IUART1 2	`nxp,imx-iuart`
Timer	on-chip	per-core ARM architected timer1	`arm,armv8-timer`
Watchdog	on-chip	imxRT watchdog1	`nxp,imx-wdog`

`phyboard_polis/mimx8mm6/a53/smp` target

On-target memory for this board target: 1 MiB of RAM, N/A of Flash.

Type	Location	Description	Compatible
CPU	on-chip	ARM Cortex-A53 CPU4	`arm,cortex-a53`
Clock control	on-chip	i.MX CCM (Clock Controller Module) IP node1	`nxp,imx-ccm`
Counter	on-chip	NXP MCUX General-Purpose Timer (GPT)2	`nxp,imx-gpt`
Ethernet	on-chip	NXP ENET IP Module1	`nxp,enet`
	on-chip	NXP ENET MAC/L2 Device1	`nxp,enet-mac`
	on-chip	NXP ENET MDIO Features1	`nxp,enet-mdio`
	on-chip	NXP ENET PTP (Precision Time Protocol) Clock1	`nxp,enet-ptp-clock`
GPIO & Headers	on-chip	i.MX GPIO1 4	`nxp,imx-gpio`
I2C	on-chip	NXP II2C4	`nxp,ii2c`
Interrupt controller	on-chip	ARM Generic Interrupt Controller v31	`arm,gic-v3`
LED	on-board	Group of GPIO-controlled LEDs1	`gpio-leds`
Miscellaneous	on-chip	NXP i.MX Resource Domain Controller (RDC)1	`nxp,rdc`
Pin control	on-chip	This compatible binding should be applied to the device’s iomuxc DTS node1	`nxp,imx-iomuxc`
Pin control	on-chip	The node has the ‘pinctrl’ node label set in MCUX SoC’s devicetree1	`nxp,imx8mp-pinctrl`
Power management CPU operations	on-board	Power State Coordination Interface (PSCI) version 1.11	`arm,psci-1.1`
PWM	on-chip	NXP i.MX PWM controller4	`nxp,ipwm`
Serial controller	on-chip	This binding gives a base representation of the NXP iMX IUART1 2	`nxp,imx-iuart`
Timer	on-chip	per-core ARM architected timer1	`arm,armv8-timer`
Watchdog	on-chip	imxRT watchdog1	`nxp,imx-wdog`

`phyboard_polis/mimx8mm6/m4` target

On-target memory for this board target: 128 KiB of RAM, 128 KiB of Flash.

Type	Location	Description	Compatible
CPU	on-chip	ARM Cortex-M4 CPU1	`arm,cortex-m4`
ARM architecture	on-chip	i.MX ITCM (Instruction Tightly Coupled Memory)1	`nxp,imx-itcm`
ARM architecture	on-chip	i.MX DTCM (Data Tightly Coupled Memory)1	`nxp,imx-dtcm`
CAN	on-board	Microchip MCP251XFD SPI CAN FD controller1	`microchip,mcp251xfd`
Clock control	on-chip	i.MX CCM (Clock Controller Module) IP node1	`nxp,imx-ccm`
GPIO & Headers	on-chip	i.MX GPIO1 4	`nxp,imx-gpio`
Interrupt controller	on-chip	ARMv7-M NVIC (Nested Vectored Interrupt Controller)1	`arm,v7m-nvic`
IPM	on-chip	i.MX Messaging Unit1	`nxp,imx-mu`
LED	on-board	Group of GPIO-controlled LEDs1	`gpio-leds`
Pin control	on-chip	This compatible binding should be applied to the device’s iomuxc DTS node1	`nxp,imx-iomuxc`
Pin control	on-chip	The node has the ‘pinctrl’ node label set in MCUX SoC’s devicetree1	`nxp,imx8mp-pinctrl`
Serial controller	on-chip	This binding gives a base representation of the NXP iMX IUART1 3	`nxp,imx-iuart`
SPI	on-chip	NXP i.MX ECSPI controller3	`nxp,imx-ecspi`
Timer	on-chip	ARMv7-M System Tick1	`arm,armv7m-systick`

Note

It is recommended to disable peripherals used by the M4-Core on the Linux host.

Connections and IOs

The following components are tested and working correctly.

UART:

UART4 is only accessible from the M4-Core of the phyBOARD-Polis. Taking this into account and to minimize problems if both clusters are running, Zephyr OS is configured by default to use UART4 with M4-Core and UART3 with Cortex-A53 cluster.

Board Name	SoM Name	Usage
RS232/485	UART1	RS232 / RS485 with flow-control
To WiFi Module	UART2	UART to WiFi/BLE Module
Debug USB(A53)	UART3	UART Debug Console via USB
Debug USB(M4)	UART4	UART Debug Console via USB

Note

Please note, that the to UART2 connected Wifi/BLE Module isn’t working with Zephyr yet.

Warning

On Boards with the version number 1532.1 UART4 isn’t connected to the Debug USB. UART4 connects to pin 10(RX) and 12(TX) on the X8 pinheader.

SPI:

ECSPI is disabled by default. On phyBOARD-Polis, the SoC’s ECSPI3 is not usable. ECSPI1 is connected to the MCP2518 CAN controller with a chip select. Another device can be connected via the expansion header (X8): PIN 5, 6, 7, 8 (CS, MOSI, MISO, SCLK). ECSPI2 is connected to the TPM module. Currently the TPM module is not supported by Zephyr.

Note

Please note, that it is necessary to disable ECSPI1 in the Linux devicetree before you can use it on the M4-Core with Zephyr. See section “Disabling Interfaces in Linux” for more information.

LEDs:

Zephyr has the 3-color status LED configured. The led0 alias (the standard Zephyr LED) is configured to be the blue LED. The LED can also light up in red and green.

GPIO:

GPIO is fully functional. GPIO usage can interfere with Linux if GPIO isn’t disabled on Linux

The Pinout of the phyBOARD-Polis can be found here:

PHYTEC website

CAN:

The MCP2518 is connected via ECSPI1. The CAN interface is disabled by default to not interfere with Linux on the A53-Core. If you want to use the CAN interface you need to disable ECSPI in the Linux devicetree.

Warning

There is a bug in the MCP2518 driver that causes the enable pin of the transceiver to be not set. This causes a ENETDOWN error when trying to send a CAN frame. Receiving CAN frames in listen-only mode is possible.

System Clock

The M4 Core is configured to run at a 400 MHz clock speed.

Programming and Debugging (A53)

Starting the A53-Core via U-Boot

As an example, one can build an image with the Basic Synchronization sample:

# From the root of the zephyr repository
west build -b phyboard_polis/mimx8mm6/a53 samples/synchronization

Load the compiled zephyr.bin to memory address 0x93c00000. This should output something like this:

u-boot=> tftp 0x93c00000 192.168.3.10:zephyr.bin
Using ethernet@30be0000 device
TFTP from server 192.168.3.10; our IP address is 192.168.3.11
Filename 'zephyr.bin'.
Load address: 0x93c000000
Loading: ##########
         9.4 MiB/s
done
Bytes transferred = 49288 (c088 hex)

Then use the following command to boot Zephyr on the core0:

u-boot=> dcache off; icache flush; go 0x93c00000;

The A53-Core is now started up and running with the following console output (UART3):

## Starting application at 0x93C00000 ...
*** Booting Zephyr OS build v4.3.0-7560-g0dff993ff889 ***
thread_a: Hello World from cpu 0 on phyboard_polis!
thread_b: Hello World from cpu 0 on phyboard_polis!
thread_a: Hello World from cpu 0 on phyboard_polis!
thread_b: Hello World from cpu 0 on phyboard_polis!

Cortex-A53 SMP

The default SMP variant runs on all four Cortex-A Cores, it could be changed by disabling some A53 Core nodes in dts and change CONFIG_MP_MAX_NUM_CPUS to the count of enabled A53 Cores in dts.

Building SMP kernel, for example, with the Basic Synchronization sample:

# From the root of the zephyr repository
west build -b phyboard_polis/mimx8mm6/a53/smp samples/synchronization

And running it, would result in the following console output (UART3):

## Starting application at 0x93C00000 ...
*** Booting Zephyr OS build v4.3.0-7560-g0dff993ff889 ***
Secondary CPU core 1 (MPID:0x1) is up
Secondary CPU core 2 (MPID:0x2) is up
Secondary CPU core 3 (MPID:0x3) is up
thread_a: Hello World from cpu 0 on phyboard_polis!
thread_b: Hello World from cpu 1 on phyboard_polis!
thread_a: Hello World from cpu 0 on phyboard_polis!
thread_b: Hello World from cpu 1 on phyboard_polis!

Programming and Debugging (M4)

The i.MX8MM does not have a separate flash for the M4-Core. Because of this the A53-Core has to load the program for the M4-Core to the right memory address, set the PC and start the processor. This can be done using U-Boot or Linux via remoteproc.

The M4-Core can either use the TCM (Tightly Coupled Memory) or the OCRAM memory. Please note that remoteproc only supports the TCM memory region.

These are the memory mapping for A53 and M4:

Region	Cortex-A53	Cortex-M4 (System Bus)	Cortex-M4 (Code Bus)	Size
OCRAM	0x00900000-0x0093FFFF	0x20200000-0x2023FFFF	0x00900000-0x0093FFFF	256KB
TCMU	0x00800000-0x0081FFFF	0x20000000-0x2001FFFF		128KB
TCML	0x007E0000-0x007FFFFF		0x1FFE0000-0x1FFFFFFF	128KB
OCRAM_S	0x00180000-0x00187FFF	0x20180000-0x20187FFF	0x00180000-0x00187FFF	32KB

For more information about memory mapping see the i.MX 8M Applications Processor Reference Manual (section 2.1.2 and 2.1.3)

At compilation time you have to choose which RAM will be used. This configuration is done in boards/phytec/phyboard_polis/phyboard_polis_mimx8mm6_m4.dts with “zephyr,flash” and “zephyr,sram” properties.

The following configurations are possible for the flash and sram chosen nodes to change the used memory area:

"zephyr,flash"
- &tcml_code
- &ocram_code
- &ocram_s_code

"zephyr,sram"
- &tcmu_sys
- &ocram_sys
- &ocram_s_sys

By default Zephyr is configured to use the TCM memory area and CONFIG_XIP is disabled. If you want to use the OCRAM memory area you have to enable CONFIG_XIP.

Starting and using the M4-Core from U-Boot and Linux

Loading binaries and starting the M4-Core is supported from Linux via remoteproc or from U-boot by directly copying the firmware binary. Please check the phyCORE-i.MX 8M Mini BSP Manual for more information.

Usually M4-Core applications need to communicate to the Linux host. Typically OpenAMP / RPMsg is used for that. You can find more Information about how to use OpenAMP with the PHYTEC BSP here: Coprocessor Documentation

Flashing and Debugging via JTAG

The phyBOARD-Polis can be debugged using a JTAG or SWD debug adapter. A Segger JLink can be connected to the compatible JTAG connector on Phytec’s PEB-EVAL-01 shield.

Here is an example for the Hello World application:

# From the root of the zephyr repository
west build -b phyboard_polis/mimx8mm6/m4 samples/hello_world
west flash

The console should now show the output of the application:

*** Booting Zephyr OS build v3.7.0 ***
Hello World! phyboard_polis/mimx8mm6/m4

Starting a debug session is similar to flashing:

# From the root of the zephyr repository
west build -b phyboard_polis/mimx8mm6/m4 samples/hello_world
west debug

Debugging

The phyBOARD-Polis can be debugged using a JTAG Debugger. The easiest way to do that is to use a SEGGER JLink Debugger and Phytec’s PEB-EVAL-01 Shield, which can be directly connected to the JLink. You can find the JLink Software package here: JLink Software

To debug efficiently you should use multiple terminals:

(But its also possible to use west debug)

After connecting everything and building with west use this command while in the directory of the program you built earlier to start a debug server:

host$ west debugserver

West automatically connects via the JLink to the Target. And keeps open a debug server.

Use another terminal, start gdb, connect to target and load Zephyr on the target:

host$ gdb-multiarch build/zephyr/zephyr.elf -tui
(gdb) targ rem :2331
Remote debugging using :2331
0x1ffe0008 in _vector_table ()
(gdb) mon halt
(gdb) mon reset
(gdb) c
Continuing.

The program can be debugged using standard gdb techniques.

Disabling Interfaces in Linux

If Zephyr is used on the M4-Core while Linux runs on the A53-Core, it is recommended to disable the Interfaces used by the M4-Core to avoid conflicts. More simple interfaces can be enabled on both cores at the same time, for example GPIO. If you do that, keep in mind that conflicts can still arise.

For more complex interfaces like SPI it is necessary to disable them in the Linux devicetree, otherwise Linux will probably crash in a panic, resetting the SoC. For example: disabling ECSPI1 in Linux to use it on the M4-Core with Zephyr:

Create a new file called disable_spi.dts with the following content:

/dts-v1/;
/plugin/;

/ {
   fragment@0 {
      target = <&ecspi1>;
      __overlay__ {
            status = "disabled";
      };
   };
};

Compile the file with the dtc compiler to a devicetree blob:

$ dtc -@ -I dts -O dtb -o imx8mm-phyboard-polis-disable-spi.dtbo disable_spi.dts;

Copy the compiled file to the boot partition of the target.
Add the filename to the /boot/bootenv.txt file at the end of the line.
Reboot the target, the SPI interface is now disabled in Linux.

phyBOARD-Polis i.MX8M Mini